Re: type hinting

Hi Sam, On Feb 6, 2008 4:08 PM, Sam Barrow <sam@sambarrow.com> wrote: > > On Wed, 2008-02-06 at 15:31 +0100, Pierre Joye wrote: > > HI Sam, > > > > On Feb 6, 2008 2:33 PM, Sam Barrow <sam@sambarrow.com> wrote: > > > On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote: > > > > On Wed, 6 Feb 2008, Sam Barrow wrote: > > > > > > > > > On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote: > > > > > > > > > > > > I still we should add simple static typehints (ie. just the types that > > > > > > we use in the manual) - and they should behave in the same way as the > > > > > > other type hints that we laready have. > > > > > > > > > > True, but we have to consider the fact that we don't have enough > > > > > support > > > > > on that side. > > > > > > > > This is not some election campaign were you change what you believe in > > > > just to go get followers. So no, I will not take that into > > > > consideration. > > > > > > > > Derick > > > > > > When did I change my opinion. I'm putting forth a compromise that may be > > > able to make both sides happy. If we can all agree to a scalar type hint > > > I don't see anything wrong with that. > > > > A scalar type brings none of the advantages of a full set of type > > hints. I see zero gain to scalar in comparison to what we have now. > > I'm still in favor of having all types available. > > But saying that is like saying that the array type hint has no gain. It is not the same. If I expect an array, I will loop through it. > function insertIntoDb(scalar $table, scalar $value) { > } > > This can prevent an array or object from accidentally being put into a > database field (which won't work). Plus, since the hint is scalar, us > strict typing people can insert (int) 1, and the dynamic typing people > can insert (string) "1" or (bool) TRUE. Having a scalar type hint will help a very very little but brings close to no benefits besides this exact example. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org