Namespaces cannot come soon enough to PHP

[mx2k]

Because it ads virtually no value to your code -- except some minor benefits that can equally well be implemented via in-code documentation -- while (sometimes severely) limiting your options.

And a question inspired by some of your posts above: what other languages besides PHP have type hinting? I'm not saying there are none, I'm just not aware of any. (Note: I'm talking about type hinting, not static typing. There's a huge difference.)

i'd imagine typehinting is php's way of being flexible to allow somewhat static typing in the code in function signatures.

i don't see it as bad, especially when you want to enforce passing an object that might be of Type C/or interface x because you need to make sure that object has a certain method or property. So you can have class G inherit from class C and it should still be able to pass the type hint, or you use interface x as a type hint, you should be able to pass any object that uses that interface.

And type hinting failures should be found during the development and testing process. Now, if you were using an IDE that picked up typehints, it should display it as an error before you ever run the script.

In a framework like prado or something to that nature, it has it's uses.

[coo_t2]

[snip]

And type hinting failures should be found during the development and testing process. Now, if you were using an IDE that picked up typehints, it should display it as an error before you ever run the script.

In a framework like prado or something to that nature, it has it's uses.

Assuming you could test for all the cases where the wrong type might be passed in, wouldn't doing this negate the usefullness of typehinting in the first place?

[BerislavLopac]

i don't see it as bad, especially when you want to enforce passing an object that might be of Type C/or interface x because you need to make sure that object has a certain method or property. So you can have class G inherit from class C and it should still be able to pass the type hint, or you use interface x as a type hint, you should be able to pass any object that uses that interface.

And this is exactly the mistaken view which drives the addition of useless static features to dynamic languages.

This part in particular: "you want to enforce passing an object that might be of Type C/or interface x because you need to make sure that object has a certain method or property". But you don't need to know the type to make sure that the object has a certain interface! All you need is to call the required method; that's called "duck typing", and works nicely in other dynamic languages like Python and Smalltalk, and there is no reason why shouldn't it work in PHP.

Actually, this statement is not really true: making sure that an object is of a certain type doesn't makes sure that it contains a certain property, if the type doesn't contain it. Don't forget an important issue: it's not the type that determines the interface, it's the interface that determines the type.

[Luke Redpath]

Very true.

"If it walks like a duck, and quacks like a duck, then it might as well be a duck"

[Luke Redpath]

In the interest of fairness...The flipside of the coin

Read the comments for further discussion. At the end of the day though, it starts to boil down to a static vs dynamic typing debate. Don't think there is any need to retread old ground.

[DougBTX]

In the interest of fairness...The flipside of the coin

If you have a method
calculate_area( x, y)
it matters a *lot* if x and y are in units of inches, meters, or worse, seconds or gallons.
People who think just specifying the number of bits used to represent the values (essentially what C/Java/C#, etc do) are just fooling themselves if they think they're gaining any benefit from their type system.

(Though I'm perfectly happy using inchmeters as a unit of area )

Douglas

[jayboots]

A problem I have with duck typing (which I do think is often appropriate) is the same thing that adherents tend to point to as its benefit: it only specifies affinity at the method signature level. It has no idea if correlation is important and it requires many instances of affinity -- as opposed to a single instance to a higher-order structure (ie: an interface) with a typehint.

With typehinting, entered code is gauranteed of certain relationships. If this has no benefit to you or your code -- don't use it -- it is not mandatory; however, to dismiss it entirely goes too far in my mind. Two different classes can have methods with the same name, yet different semantic meanings. Duck typing doesn't acknowledge that because it is purely syntax driven -- if you pass an object, then as long as the desired method signature is there on the object, it is happy to call it -- regardless of semantics. Often this is fine -- but not always.

Why do we bother creating class relationships and interface specs? According to duck typing, we should be just as happy to use groups of single, disconnected functions and collections and hope everything works out okay at runtime. Okay, that's too drastic -- but duck typing does say: "if you passed me an object and it has the method signatures that I am expecting, then the object must be the sort that I was expecting after all." On the surface, that makes great sense -- but the underlying assumption shouldn't be ignored. If you don't know the object, you don't know what it really does: at best, you may be able to guess its features but not how it will behave.

"If it walks like a duck and talks like a duck -- it must be a duck" is only a catch-phrase. In reality it could be a baby duck. It could be a cartoon character. It could be a kid in a costume. You can never know how many features you will have to test to gaurantee a duck (and duck typers often don't even in-code test if a method can be called -- they just call it and hope for the best). That's why I think that relying on duck typing alone is like programming by faith.

[Luke Redpath]

(and duck typers often don't even in-code test if a method can be called -- they just call it and hope for the best). That's why I think that relying on duck typing alone is like programming by faith.

Whilst I don't disagree with you in general (and I prefer duck typing over interfaces) I think if your code is well tested, then calling it "programming by faith" is a little exaggerated.

[jayboots]

Whilst I don't disagree with you in general (and I prefer duck typing over interfaces) I think if your code is well tested, then calling it "programming by faith" is a little exaggerated.

True, that is reasonable criticism -- I figured I was stretching it a bit there Still, test-cases do not write themselves -- and other users (or extenders) may not themselves implement appropriate test cases.

[DougBTX]

If you don't know the object, you don't know what it really does

When do you ever really 100% know what an object will do when you call its methods?

That's why I think that relying on duck typing alone is like programming by faith.

If you are a function, you always rely on your caller to provide the correct arguments. Is this $string a first name or a last name? You can call that faith if you like. As a function, you can only be sure of yourself, and only within the limits of your tests, whether they are tests you apply in your head, or better, tests you apply in code. If something does go wrong, then you know it is a problem with the calling code.

Douglas

[jayboots]

Hi.

When do you ever really 100% know what an object will do when you call its methods?

When the object is tested and known to conform to its interface? At some point, you have to trust your contract. I think that perhaps strict duck typers are willing to do that at a lower level of granularity as compared to strict type hinters. It seems to me that the main difference is that type hinters want to declare the contract explicitly and that duck typers think that this comes at the cost of giving up too much flexibility. As they are different goals, I think they can have differing applicability based on present needs.

If you are a function, you always rely on your caller to provide the correct arguments. Is this $string a first name or a last name? You can call that faith if you like. As a function, you can only be sure of yourself, and only within the limits of your tests, whether they are tests you apply in your head, or better, tests you apply in code. If something does go wrong, then you know it is a problem with the calling code.

One of the points of typehinting is to prevent upstream errors from propogating. FWIW, I don't trust incoming parameters -- I validate them and error out on failure. I find that type hinting helps streamline that sort of process.

Greetings.

[dagfinn]

Hi dagfinn.

FWIW, I try to follow the policy of only typehinting on interfaces or abstracts (if I am forgoing an interface) -- at any rate, generics. These tend to have much shorter names than concretes and help promote a reasonable level of re-use while still satisfying a minimal level of checking. If I find that I want to typehint a concrete I begin to think that my design is going astray since that would introduce harder dependancies.

Cheers.

I guess it depends on the situation. If you have stable abstractions with short names, you're right. At this point, the abstractions I'm using in this project are not stable and don't have short names. I suppose I could do it after the code stabilizes a bit more, but who wants to change stable code?

[Luke Redpath]

and other users (or extenders) may not themselves implement appropriate test cases.

Well, thats their fault

[mx2k]

Actually, this statement is not really true: making sure that an object is of a certain type doesn't makes sure that it contains a certain property, if the type doesn't contain it. Don't forget an important issue: it's not the type that determines the interface, it's the interface that determines the type.

it depends on how you program and its subjective. you're opinion stems from your style and preferances of programming and it offers no relevance of decent advice, when it comes to diversity of programming style, unless of course someone takes up your style of programming.

In php, if I create the method "public final function Write()" in the super class of Type C, that is a method i could expect it without defining an interface in any class that inherits from Type C. And just because i find that useful, does not mean you have to, but it doesn't mean its not useful.

There are alot of developers who come from a static type of background, rather than dynamic. One of the reasons of php's popularity it's appeal to developers from different backgrounds and its flexible in style. This is something that the developers at Zend has done right in order to help people transition to the language and appeal to a mass market.

and if you don't believe me that php was designed to be flexible with coding styles, when why add alternatives like if & end if/ while endwhile?

Assuming you could test for all the cases where the wrong type might be passed in, wouldn't doing this negate the usefullness of typehinting in the first place?

you can't assume everyone that uses your code writes tests, nor can you assume that the code base is always available, it could be encoded and all you have access to is the api documentation.

I imagine, it might also help to speed up testing to know that this method or function is failing because the object passed was of the wrong type. Not to mention this is useful when you are developing code to be used by other developers.

It seems to me that people who think typehinting is useless is in the mindset that they will have access to the full code & they probably don't have to interlope with other people's code base that often or do not have to develop for others to intregrate with their code with ease.

[DougBTX]

At some point, you have to trust your contract. I think that perhaps strict duck typers are willing to do that at a lower level of granularity as compared to strict type hinters. It seems to me that the main difference is that type hinters want to declare the contract explicitly and that duck typers think that this comes at the cost of giving up too much flexibility.

I'd agree with that.

Note that you can't know whether an object passed to you even has unit tests, let alone whether it passes them. It may even be a mock object

Douglas

[jayboots]

I imagine, it might also help to speed up testing to know that this method or function is failing because the object passed was of the wrong type. Not to mention this is useful when you are developing code to be used by other developers.

Good point. Another point with typehinting is that you can see directly that a specific interface is referenced. As you gain familiarity with the various interfaces of the system, you begin to understand what is implied and required by a function simply by reading its signature rather than having to read its whole body.

Compare to duck typing in which you have to rely on documentation to understand what sort of features a function will require of its passed objects. For real clarity, this documentation has to be repeated everywhere that the features are used instead of simply documenting the single interface.

[jayboots]

Note that you can't know whether an object passed to you even has unit tests, let alone whether it passes them. It may even be a mock object

Yes and typehinting doesn't prevent mocks.

Well, it seems that this topic strayed from namespaces, yes?

[Dr Livingston]

if you passed me an object and it has the method signatures that I am expecting, then the object must be the sort that I was expecting after all.

You can't alone, depend on that in my view. I would go as far as to say that you should also take into consideration, defensive programming, in that type hinting has it's use there as well.

As you gain familiarity with the various interfaces of the system, you begin to understand what is implied and required by a function simply by reading its signature rather than having to read its whole body.

In reality it could be a baby duck.

In fact, that said duck could have it's head in the water, and it's a*** up in the air... Where does that leave you then?

[jayboots]

I suppose I could do it after the code stabilizes a bit more, but who wants to change stable code?

True, true, but wouldn't doing so be inline with refactoring techniques?

[DougBTX]

Well, it seems that this topic strayed from namespaces, yes?

Yea, that gets a bit boring, as we know we want namespaces

I just have a feeling we are all going to be dissapointed when/if we do get namespaces. I think the best thing on the cards at the moment are more like "class packages" than namespaces, though that's better than nothing.

PHP has a lot of momentum as a procedural language, I wonder how the new Zend framework will change that. I also wonder how development of the Zend framework will be affected by namespaces, if at all.

Douglas

[DougBTX]

Compare to duck typing in which you have to rely on documentation to understand what sort of features a function will require of its passed objects. For real clarity, this documentation has to be repeated everywhere that the features are used instead of simply documenting the single interface.

Hmm, you see, that's not been my experience so far, I'll get back to you in ten years.

I think the situation is deaper than the level we've been discussing, I think we've been making too many assumptions. One of them is probably that coding for the web is difficult.

Douglas

[mx2k]

One of them is probably that coding for the web is difficult.

it depends yes you could very easily throw together a database driven website with php in no time.

but.... there are things to consider, maintability, integration, reuse, easy to deploy, usability, readable, well tested..... thinking on those lines will both cost you time in short run but save you time in the long run. code generation <3

[DougBTX]

but.... there are things to consider, maintability, integration, reuse, easy to deploy, usability, readable, well tested..... thinking on those lines will both cost you time in short run but save you time in the long run. code generation <3

All important things, but I'm not sure they compare in difficulty to problems like designing a high performance SQL database (which contains all the above as side issues) or building a usable/beautiful user interface (which also contains all the above issues).

But hay, who am I?

Douglas

[Forbes]

A lot of good too if you look at the commits he has made, the docs he contributed and so on. He may be maverick sometimes but look at some of the ways others act. Pierre is basically on a witch hunt and is going around calling several devs (not just Derick) liars. Basically, this is dirty laundry being aired in a public forum. Sometimes mistakes are made during the development process and typically that means the process isn't good enough not that one or another developer is a bad egg. I hope we don't start pointing fingers.

What is this? A soap opera?

I'm guessing Microsoft are lovin' this, what with them working on a LAMP alternative.

What with all these hissy fits and tears-against-the-photocopier episodes, I'm just wondering if some third-party needs to be involved to steady things...

[mx2k]

All important things, but I'm not sure they compare in difficulty to problems like designing a high performance SQL database (which contains all the above as side issues) or building a usable/beautiful user interface (which also contains all the above issues).

But hay, who am I?

Douglas

the database i could definitely see... but the ui? i guess it depends on the tools/language/environment(ie linux, windows, web, mac)? you use and what its built for. i can't speak for a linux or mac environment, i can use both, but i've never developed for either. But as for the web and windows, it hasn't been to difficult. it should be interesting once xaml is being used, i'm more used to html/css mindset anyways.

I'm guessing Microsoft are lovin' this,

they are too busy being sued, losing browser share, putting out new software, being locked out from being able to sell windows in 3rd countries right now to really worried about it. Not to mention its new war with google, partnershiping msn msg with yahoo just to interop, buying out small companies like folder share...

::sarcasm::
oh no the evil MS empire is watching you. ;-)
::end sarcasm::