Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RE: Optional scalar type hinting »

RE: Optional scalar type hinting

php.internals

Tomi Kaistila

18 years ago
Hello everyone I figured I would bring my opinion in to support of Sam's request for a more complete type hinting feature. Namely I am interested in the support for hinting scalar types on function and method arguments and I am sure it is safe for me to say that I speak for a lot of people. Most people that I know find the current type hinting, while useful, ridiculous because it looks like the job was left unfinished for whatever abstract reason. In my opinion type hinting should definitely be allowed for scalar values. As for return types, I am not so sure. So far I have found no use for such a feature in my own code, so I won't comment on it. If it is added, I welcome it for those who find it useful but if it is not added I will not loose sleep over it.
> I was thinking at something along the lines of objects also for instance: > $i = new Integer(33);
After my own experiments with the subject I concur that while it can be made to work, it is not only a bad idea (for the reasons mentioned earlier) it is also redundant and just unnecessary. There is a lot better way to accomplish the same and that by allowing scalar values to be hinted. It is simpler, cleaner, and easier to implement.
> What if type hinting just generated an E_NOTICE. Nothing more for the > time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since if I write a piece of code that hints that the argument for a-whatever method needs to be an integer it seems useless if the user of my library can avoid the issue just by supressing lesser errors and those who do not need to write extensive error handling code to respond to this sort of error (if they indeed deem it necessary to do so). While hinting is, and should remain, optional, when it is used it should be enforced. After all the user of my library has the option to dump it and go for another library that does not force types. That is the beauty of having options. Tomi Kaistila PHP Developer

Sam Barrow

18 years ago
I think E_WARNING would be appropriate. That's what happens when you omit an argument to a function right? And about function return type hinting, I don't think it would be as useful as parameter type hinting, but it would be useful. Mostly for stuff like declaring an abstract function in a parent class that must return a certain type. class a { abstract public function getNumber() returns int ; } class b extends a { public function getNumber() { return rand() * 3463 ; } } class c extends a { public function getNumber() { return 'I\'m going to mess everything up by returning a string.' ; // Would cause error with type hinting. } } On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:

Alain Williams

18 years ago
On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote:
> I think E_WARNING would be appropriate. That's what happens when you > omit an argument to a function right?
The other thing to note about type hinting is that it could result in faster code. The value is checked and if needed converted (eg string -> integer) when the function is called; it then need not be converted again when it is used in the function. This will presumably be a win if the value is used more than once.
-- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include <std_disclaimer.h>

Markus Fischer

18 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Alain Williams wrote:
> On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote: >> I think E_WARNING would be appropriate. That's what happens when you >> omit an argument to a function right? > > The other thing to note about type hinting is that it could result in faster code. > The value is checked and if needed converted (eg string -> integer) when the > function is called; it then need not be converted again when it is used in > the function. This will presumably be a win if the value is used more than once.
I don't think that automagic conversion of types is a good idea. When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results according to the documentation but not always very intuitive. I sense a possible small trap, and after all type hints should help developers get code right and spot problems easier without less work. PHP supports explicit casting and that should be used for that. Because if this results in a problem alter in the code you know who to blame: yourself, and not the automagic behavior of PHP. my 2c, - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfStA1nS0RcInK9ARAu/dAKDNOMC7M1X8CyrjyCrpzt0/oiLsCgCg2YSY YAUYre0HTc3dLxsbHTu7+Ik= =KXMz -----END PGP SIGNATURE-----

Stanislav Malyshev

18 years ago
> When the type hint says I want an integer, then only integer should be > accepted; no casting should be done. It may give predictable results
Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Markus Fischer

18 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Stanislav Malyshev wrote:
>> When the type hint says I want an integer, then only integer should be >> accepted; no casting should be done. It may give predictable results > > Why people that want Java just don't use Java I wonder? PHP never was a > strict static typed language.
I can't answer you that one :) I want PHP and not Java. Yet I would like to have type hinting. Don't see a conflict here. But with the current situation it feels very awkward. We get class and array type hints but not the other scalar types?! :-/ - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfTDj1nS0RcInK9ARAqL3AJsFeFxW/m+xonir+ukKEtOHU/m/WQCfetSx wvy6jLFuSclijBClsADGG+8= =8Lwh -----END PGP SIGNATURE-----

Stanislav Malyshev

18 years ago
> But with the current situation it feels very awkward. We get class and > array type hints but not the other scalar types?! :-/
Arrays and objects aren't scalar types, so "other" scalar types are in fact all on them.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Markus Fischer

18 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, you're right. However to me it's an unimportant factor but maybe not for the ones who don't like to see type hints (but I don't know what there arguments are). thanks, - - Markus Stanislav Malyshev wrote:
>> But with the current situation it feels very awkward. We get class and >> array type hints but not the other scalar types?! :-/ > > Arrays and objects aren't scalar types, so "other" scalar types are in > fact all on them.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfTWe1nS0RcInK9ARAvlJAKCvC5rcQ1je1wbnht3GCacQ7E5HoQCgq/Ix H9GKXUubMQupLwhx1icukFM= =jQSH -----END PGP SIGNATURE-----

Derick Rethans

18 years ago
On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
> > When the type hint says I want an integer, then only integer should be > > accepted; no casting should be done. It may give predictable results > > Why people that want Java just don't use Java I wonder? PHP never was a strict > static typed language.
Broken record perhaps? I am getting a bit tired of this "just use Java argument", it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Sam Barrow

18 years ago
Thank you. As long as a feature is useful, why not add it? Just because some people don't find it useful, this is not at all a reason to completely discard the idea, especially when the only argument is "well PHP doesn't need that so just use another language". On Thu, 2008-01-03 at 20:23 +0100, Derick Rethans wrote:

Derick Rethans

18 years ago
On Thu, 3 Jan 2008, Sam Barrow wrote:
> Thank you. As long as a feature is useful, why not add it?
With that statement I don't agree though. It needs to be usefull for a more general public, and not introduce a huge performance loss for example. Derick PS: Top-posting is considered evil on a mailinglist.
-- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Sam Barrow

18 years ago
On Thu, 2008-01-03 at 20:50 +0100, Derick Rethans wrote:
> With that statement I don't agree though. It needs to be usefull for a > more general public, and not introduce a huge performance loss for > example.
You're right, I didn't mean that like it sounded. But a feature that maintains backwards compatibility and doesn't have a major disadvantage for those who choose not to use it is almost always good. In this case, it will benefit many, and to those who choose not to use it, they will probably never even notice it's there. So why not? Because it somehow goes against the ideology of some PHP users? I'm sorry but I just don't see that as reason enough to throw away something that could be very useful. PHP is quickly moving from an easy to learn unprofessional scripting language into an enterprise-level scalable language. Look at it's newer enhanced XML capabilities, improved OO engine, and all of the third-party integration libraries. Finer-grained control over an application (which type hinting contributes to) is something that fits the newer and better language that PHP is becoming.

Sam Barrow

18 years ago
Just so anyone who wants it has it, I have attached the last version of my patch. Note that it still issues a fatal error but this can be changed very easily, would take me about 2 minutes. Full specs: Type hinting patch allows for 8 new type hints, in addition to array and class type hinting. - Integers (specified by "int", "integer", or "long") - Floats (specified by "float", "double", or "real") - Numbers (matches integers and floats, specified by "num" or "number") - Strings (specified by "string") - Booleans (specified by "bool" or "boolean") - Scalars (matches strings, booleans, and numbers; specified by "scalar") - Resources (specified by "resource") - Objects (matches any object, specified by "object") The patch specifies a constant, PATCH_SCALAR_TYPE_HINTING, just there to indicate that the patch is installed. On Thu, 2008-01-03 at 20:23 +0100, Derick Rethans wrote:

Tomi Kaistila

18 years ago
> Broken record perhaps? I am getting a bit tired of this "just use Java > argument", it's perhaps even a bit arrogant. From what I read there is > plenty of people that want type hints for static types - there's a few > patches out there, it doesn't slow down the general case. So why should > we *not* add it? (And yes, I changed my mind)
Same here. I am getting generally tired of the attitude some politically-correct people seem to have about writing "javaish" code. What the heck is "javaish" code anyway? Most features that exist in both PHP and Java can also be found in myriad of other languages and it has so far not stopped the development team from adding a feature when it is clearly useful and (most importantly) desired an uncounted number of people. In fact those who oppose the feature seem only capable of doing so with hair-splitting rhetorics.
> am I the only one to consider E_FATAL (as generated for class typehints) > makes type hinting useless - given that there is no compile stage at which > to catch typehint related mistakes
In principle you are correct. But E_FATAL errors should not happen in a program that is in production use. If they do, it seems someone was not doing their job properly. I am not convinced throwing an exception is the best course of action. If it was, you might make the argument that all errors should be exceptions, while traditionally it is the other way around and changing that is beyond the scope of this thread. I actually like the current "division of labor" when it comes to error handling. When PHP detects an error, it should actually be an error. Exceptions are convenient for the code that you as a PHP developer can throw. They are especially a blessing when writing library code. That way exceptions work for the error management, instead of competing with it. I say use E_WARNING at this stage. If there is some large redecorating with PHP's error handling in the future, it can be changed then. Tomi Kaistila PHP Developer

Sam Barrow

18 years ago
On Thu, 2008-01-03 at 22:01 +0200, Tomi Kaistila wrote:
> > Broken record perhaps? I am getting a bit tired of this "just use > Java > > argument", it's perhaps even a bit arrogant. From what I read there > is > > plenty of people that want type hints for static types - there's a > few > > patches out there, it doesn't slow down the general case. So why > should > > we *not* add it? (And yes, I changed my mind) > Same here. I am getting generally tired of the attitude some > politically-correct people seem to have about writing "javaish" code. What > the heck is "javaish" code anyway? Most features that exist in both PHP and > Java can also be found in myriad of other languages and it has so far not > stopped the development team from adding a feature when it is clearly useful > and (most importantly) desired an uncounted number of people. > > In fact those who oppose the feature seem only capable of doing so with > hair-splitting rhetorics.
Thank you, I've been thinking this stuff for a while now, ever since the attitude I got when first introducing my patch. I'm glad some people agree with me. I don't care what my code looks like, and it's not written in some holy PHP bible that PHP's one and only purpose of existence is to not be like Java. If a good feature comes along, it should be evaluated on its pros and cons, not whether or not it reminds us of Java or any other language for that matter. I'm sorry I just have no idea where people come up with this stuff. We are supposed to be thinking technically and logically as we are all obviously computer people, not like some Java-hating cult. The issue seems incredibly simple to me, if there's a good feature and it's worth adding, add it.

Jochem Maas

18 years ago
Tomi Kaistila schreef:
>> Broken record perhaps? I am getting a bit tired of this "just use Java >> argument", it's perhaps even a bit arrogant. From what I read there is >> plenty of people that want type hints for static types - there's a few >> patches out there, it doesn't slow down the general case. So why should >> we *not* add it? (And yes, I changed my mind) > Same here. I am getting generally tired of the attitude some > politically-correct people seem to have about writing "javaish" code. What > the heck is "javaish" code anyway? Most features that exist in both PHP and > Java can also be found in myriad of other languages and it has so far not > stopped the development team from adding a feature when it is clearly useful > and (most importantly) desired an uncounted number of people. > > In fact those who oppose the feature seem only capable of doing so with > hair-splitting rhetorics. > >> am I the only one to consider E_FATAL (as generated for class typehints) >> makes type hinting useless - given that there is no compile stage at which >> to catch typehint related mistakes > In principle you are correct. But E_FATAL errors should not happen in a > program that is in production use. If they do, it seems someone was not doing > their job properly.
you are right, they shouldn't - but who can say that every execution permutation has been tested and hammered shut in their code (let alone someone else 3rd party lib or extension)? in practice mistakes do occur - and saying someone has not been doing their job properly is little consilation to the end user, client or manager (who gets a white screen of death) ... there is no reason not to let the application try to gracefully handle a mistake like this ... besides I was under the impression that E_FATAL meant the engine was in an unstable state and was unable to continue execution - I don't see why a typehint failure would cause an unstable engine state (rather the engine is presuming that the code is *going* to create an unstable state if it were to continue ... which is not very helpful in my book).
> > I am not convinced throwing an exception is the best course of action. If it > was, you might make the argument that all errors should be exceptions, while > traditionally it is the other way around and changing that is beyond the > scope of this thread. I actually like the current "division of labor" when it > comes to error handling. > > When PHP detects an error, it should actually be an error. Exceptions are > convenient for the code that you as a PHP developer can throw. They are > especially a blessing when writing library code. That way exceptions work for > the error management, instead of competing with it. > > I say use E_WARNING at this stage. If there is some large redecorating with > PHP's error handling in the future, it can be changed then.
that is a very sane arguement. I'll have to concede :-)

Stanislav Malyshev

18 years ago
> patches out there, it doesn't slow down the general case. So why should > we *not* add it? (And yes, I changed my mind)
My opinion is that the language is not a salad of features that somebody somewhere found useful. The language should have some directions and properties that make it easy to understand and handy to work with. Having both strict and non-strict typing in the same language does not seem like a good idea to me.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Sam Barrow

18 years ago
On Thu, 2008-01-03 at 12:27 -0800, Stanislav Malyshev wrote:
> > patches out there, it doesn't slow down the general case. So why > should > > we *not* add it? (And yes, I changed my mind) > > My opinion is that the language is not a salad of features that somebody > somewhere found useful. The language should have some directions and > properties that make it easy to understand and handy to work with. > Having both strict and non-strict typing in the same language does not > seem like a good idea to me.
In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as dynamic typing. I have numerous cases where I will have a type hinted parameter and a non type hinted parameter in the same function. This way we can have maximum flexibility where useful, but also control where needed. Keep in mind, this is not "strict typing" in its correct definition. Strict typing allows very little room for type conversion. This is optionally hinting the desired type of a function parameter.

Stanislav Malyshev

18 years ago
> In a way this is true, but I look at it this way. Some languages are > strictly typed, some are dynamically typed. PHP can have the best of > both worlds by having optional strict typing where desired, as well as
I do not believe trying to both eat cake and leave it intact would do us well. Mixing strict and non-strict code would be a nightmare. Absence of static type control (necessary for interpreted language) would make strictly typed code less, and not more stable. Add performance penalty from type checking and effort would be required from PHP newcomers to understand two code models instead of one - and you get the worst of both worlds, not the best.
> Strict typing allows very little room for type conversion. This is > optionally hinting the desired type of a function parameter.
That's not what I am hearing here on the list.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Tomi Kaistila

18 years ago
On Thursday 03 January 2008 22:51:27 Stanislav Malyshev wrote:
> > In a way this is true, but I look at it this way. Some languages are > > strictly typed, some are dynamically typed. PHP can have the best of > > both worlds by having optional strict typing where desired, as well as > > I do not believe trying to both eat cake and leave it intact would do us > well. Mixing strict and non-strict code would be a nightmare. Absence of > static type control (necessary for interpreted language) would make > strictly typed code less, and not more stable. Add performance penalty > from type checking and effort would be required from PHP newcomers to > understand two code models instead of one - and you get the worst of > both worlds, not the best.
I am not convinced that using type hinting would issue a big performance drawback because of type checking, for the reason that it is already happening. We can already hint types for arrays and objects. And whenever I build function that accepts a scalar value, 90% of the time I have to write a check to make sure the value is acceptable for the operation that occurs inside the function. So no matter what, type checking occurs. And so far I have been able to write lightweight programs when it has suited me, with or without type checking. It is especially in such cases where it would be helpful to skip the test myself, when I know that only the type of variables that I specify can be passed in. It is less and easier coding for me. Also, as this has been mentioned several times already, using type hinting is completely voluntary. Hence, newcomers do not need to bother with it until they are ready to try it out. If it is required in a job, then it hardly matters because it is probably one of the simplest things they might demand from a PHP developer.
> That's not what I am hearing here on the list.
I did not get this comment. Tomi Kaistila PHP Developer

Jochem Maas

18 years ago
Stanislav Malyshev schreef:
>> In a way this is true, but I look at it this way. Some languages are >> strictly typed, some are dynamically typed. PHP can have the best of >> both worlds by having optional strict typing where desired, as well as > > I do not believe trying to both eat cake and leave it intact would do us > well. Mixing strict and non-strict code would be a nightmare.
possibly like the nightmare that namespaces will give us in there current form? I mention it because use of typehinting seems alot more voluntary and less intrusive (when one encounters it in 3rd party code) than namespaces will be.
> Absence of > static type control (necessary for interpreted language) would make > strictly typed code less, and not more stable. Add performance penalty > from type checking and effort would be required from PHP newcomers to > understand two code models instead of one - and you get the worst of
newcomers? or newbies? the level of entry is being raised in all sorts of areas whether you like it or not as a by product of making php more suitable to enterprise level development. it's merely a case of not being able to please everyone all of the time (or of not having your cake and eating it)
> both worlds, not the best.
why do we then have typehinting for objects? and more recently arrays? I also seem to remember (forgive me if Im mistaken) that you we're a proponent for the increases in strictness surrounding various things related to OO. that feels rather hypocritical at some level.
> >> Strict typing allows very little room for type conversion. This is >> optionally hinting the desired type of a function parameter. > > That's not what I am hearing here on the list.
you implied in another post that php should have some kind of structured direction. how about a language spec and a formal functionality proprosal/acceptance mechanism? (preferably one that didn't allow major changes like the inclusion of namespaces into a minor release)

Sam Barrow

18 years ago
On Thu, 2008-01-03 at 12:51 -0800, Stanislav Malyshev wrote:
> > In a way this is true, but I look at it this way. Some languages are > > strictly typed, some are dynamically typed. PHP can have the best of > > both worlds by having optional strict typing where desired, as well as > > I do not believe trying to both eat cake and leave it intact would do us > well. Mixing strict and non-strict code would be a nightmare. Absence of > static type control (necessary for interpreted language) would make > strictly typed code less, and not more stable. Add performance penalty > from type checking and effort would be required from PHP newcomers to > understand two code models instead of one - and you get the worst of > both worlds, not the best.
But this is not all-out strict typing. This is simply checking types on execution of a function. I wrote the patch to follow the exact same model as array type hinting. The only difference is that instead of checking if the value is an array, it checks if it is an integer, string, bool, etc. There aren't two code models here at all. You can have a function parameter, or you can have a type-enforced function parameter. PHP newcomers can just not use type hinting if they want but I don't think this is a valid argument. As for performance, you may have a point. However it is probably no worse than array type hinting, and it's definitely faster than class type hinting, which were both deemed useful for PHP 5.1.
> > Strict typing allows very little room for type conversion. This is > > optionally hinting the desired type of a function parameter. > > That's not what I am hearing here on the list.
Sorry I don't understand, what is it you are not hearing on the list?

Pierre Joye

18 years ago
On Jan 3, 2008 8:23 PM, Derick Rethans <derick@php.net> wrote:
> On Thu, 3 Jan 2008, Stanislav Malyshev wrote: > > > > When the type hint says I want an integer, then only integer should be > > > accepted; no casting should be done. It may give predictable results > > > > Why people that want Java just don't use Java I wonder? PHP never was a strict > > static typed language. > > Broken record perhaps? I am getting a bit tired of this "just use Java > argument", it's perhaps even a bit arrogant.
It is arrogant. For what I see the strictness is making its way in php simply like OO made it. First we resist (we all remember how hard it was to introduce OO API to some extensions "why bloat it with OO?"). In doubts, we only need to look at all the OO strictness we added in the past versions. Please not that I use "we" for all php internals developers, as a group (even if we all have different opinions, we reflect only one in our releases).
> From what I read there is > plenty of people that want type hints for static types - there's a few > patches out there, it doesn't slow down the general case. So why should > we *not* add it? (And yes, I changed my mind)
Mines was always in favor of strictness for all types. As it is not necessary to create clean code, it is a really nice addition to bring PHP to yet another good level. Without talking about reducing the WTF in some cases, especially when you have to work in teams with developers not aware of PHP's "weirdness" (please don't tell me to ask them to RTFM, that's off base). Cheers,
-- Pierre http://blog.thepimp.net | http://www.libgd.org

Alain Williams

18 years ago
On Thu, Jan 03, 2008 at 10:43:39AM -0800, Stanislav Malyshev wrote:
> >When the type hint says I want an integer, then only integer should be > >accepted; no casting should be done. It may give predictable results > > Why people that want Java just don't use Java I wonder? PHP never was a > strict static typed language.
You aren't making it a strict static typed language. All that you are doing is saying that at certain points (function entry) that the values are checked and converted to certain types. If within the fuction an argument hinted as integer is used in a string context, the juggling will still happen. What you are doing to allowing the function author to protect the integrity of his code without having to resort to a regex/... to check what the arguments are.
-- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include <std_disclaimer.h>

Stanislav Malyshev

18 years ago
> You aren't making it a strict static typed language. All that you are doing > is saying that at certain points (function entry) that the values are checked > and converted to certain types. If within the fuction an argument hinted as > integer is used in a string context, the juggling will still happen.
So it's basically another way to say (string)? Again, that's not what was said by other people discussing it. But all that just to save one (string) inside function?
> What you are doing to allowing the function author to protect the integrity > of his code without having to resort to a regex/... to check what the arguments are.
If you need regex, you'd still have to use regex. Type juggling can do only so much.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Markus Fischer

18 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Malyshev wrote:
>> You aren't making it a strict static typed language. All that you are >> doing >> is saying that at certain points (function entry) that the values are >> checked >> and converted to certain types. If within the fuction an argument >> hinted as >> integer is used in a string context, the juggling will still happen. > > So it's basically another way to say (string)? Again, that's not what > was said by other people discussing it. But all that just to save one > (string) inside function?
I agree with Stanislav here. For me "type hinting" has nothing to do with "type conversion". Hinting a 'string' expects a string, nothing else, not even an object. If you need this, you need to call the function/method with an explicit conversion. It's a less 'wtf' factor going on. - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfYjI1nS0RcInK9ARAvEwAKC0WhOjaogX+f84rQArW5s071fSDgCgriWl 1+JM1RK46VVFL7Bz8pjjID0= =ORed -----END PGP SIGNATURE-----

Tomi Kaistila

18 years ago
> For me "type hinting" has nothing to do with "type conversion". Hinting > a 'string' expects a string, nothing else, not even an object.
Agreed. It seems like a way to compromise between those who support this feature and those who do not, but in a way that completely defeats the purpose of type hinting. Tomi Kaistila PHP Developer

Alain Williams

18 years ago
On Thu, Jan 03, 2008 at 07:36:48PM +0100, Markus Fischer wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > Alain Williams wrote: > > On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote: > >> I think E_WARNING would be appropriate. That's what happens when you > >> omit an argument to a function right? > > > > The other thing to note about type hinting is that it could result in faster code. > > The value is checked and if needed converted (eg string -> integer) when the > > function is called; it then need not be converted again when it is used in > > the function. This will presumably be a win if the value is used more than once. > > I don't think that automagic conversion of types is a good idea. > > When the type hint says I want an integer, then only integer should be > accepted; no casting should be done. It may give predictable results
Maybe the type checks should be stricter than normal. What are we going to want here ? * integer - possibly convert from: - string, in which case we just accept digits with an option + or - The important thing is that the *entire* string must convert - float - the standard truncate towards zero Nothing else * float - possibly convert from: - integers - standard convertion - string - accept a float in the standard formats The important thing is that the *entire* string must convert * boolean. At first glance this is easier as the convert to boolean for lots of types is well defined. In most cases the programmer would not be interested in a type check, so if he specifies it then we should be very restrictive. * string - possibly convert from: - integers & float - standard convertion - boolean - standard convertion - objects - only if they have a __toString() method
-- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include <std_disclaimer.h>

Tomi Kaistila

18 years ago
Yes it seems PHP will omit E_WARNING if you omit an argument. (Had to actually check.) Not a bad choice for an error and probably also easier to manage when you are dealing with complicated error handling in large applications. I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the simple fact that they are ignore by a major portion of PHP developers and to use them would prompt a high risk of people writing bad code. Also, now that you mentioned abstract classes, type hinting might also be useful with interfaces. Tomi Kaistila PHP Developer On Thursday 03 January 2008 19:21:21 you wrote:

Jochem Maas

18 years ago
am I the only one to consider E_FATAL (as generated for class typehints) makes type hinting useless - given that there is no compile stage at which to catch typehint related mistakes. which means there is no way to trap the issue and offer some useful/user-friendly feedback to the user (in practice it usually means the white page of death for a site visitor) E_WARNING also is not much better given that one would assume the function/method that was passed incorrect variables (according to type) wouldn't run. would an exception not be the most suitable thing to generate on a typehint error? to me anything else makes typehinting in production environments pretty much unusable unless one write code like so: function foo(Foo $f) { /* do foo stuff */ } $f = getFoo(); if ($f instanceof Foo) { foo($f); } now the issue with such code is not that it is alot more verbose than might strictly be needed but that the instanceof statement makes the typehint rather superfluous. Tomi Kaistila schreef:

Sam Barrow

18 years ago
I think we should stick with E_WARNING for now. If you want to use exceptions you can throw one in a custom error handler. I can change about 4 lines of code in my patch to have it emit an E_WARNING easily. On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:

Markus Fischer

18 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Sam, Jochem, Sam Barrow wrote:
> I think we should stick with E_WARNING for now. If you want to use > exceptions you can throw one in a custom error handler. I can change > about 4 lines of code in my patch to have it emit an E_WARNING easily. > > On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote: >> am I the only one to consider E_FATAL (as generated for class typehints) makes >> type hinting useless -
I'm currently going down exactly this road. Simplified: set_error_handler('throwit'); function throwit($code, $msg, $file, $line) { if (0 == error_reporting()) { return; } throw new Exception("$msg in $file on $line", $code); } Of course, Jochem, you're right. Exceptions would be nice. WrongArgumentException, InvalidWhateverException, ... - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfVWT1nS0RcInK9ARApW9AJ9OF+IM/bKWP5D21TDd6r8tTFhNEACgl9Ok rS+MNouW6p/4C4iKOW3/AlU= =887G -----END PGP SIGNATURE-----

Sam Barrow

18 years ago
On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote:
> Of course, Jochem, you're right. Exceptions would be nice. > WrongArgumentException, InvalidWhateverException, ...
That would be very nice. The full blown suite of exception error handlers could be a future project, depending on code contributors and community support. As for my patch, I think we can all agree on E_WARNING.

Derick Rethans

18 years ago
On Thu, 3 Jan 2008, Sam Barrow wrote:
> On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote: > > > Of course, Jochem, you're right. Exceptions would be nice. > > WrongArgumentException, InvalidWhateverException, ... > > That would be very nice. The full blown suite of exception error > handlers could be a future project, depending on code contributors and > community support. > > As for my patch, I think we can all agree on E_WARNING.
Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that should be the same for any other typehinting system that we add. Derick

Stanislav Malyshev

18 years ago
> Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that > should be the same for any other typehinting system that we add.
Then we don't add any, because without static type control it's just a ticking timebomb waiting to blow up your production code (and having application display "An internal error happened, please contact developers" is blowing up no less than having blank screen).
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Sam Barrow

18 years ago
I think E_WARNING would be appropriate. That's what happens when you omit an argument to a function right? And about function return type hinting, I don't think it would be as useful as parameter type hinting, but it would be useful. Mostly for stuff like declaring an abstract function in a parent class that must return a certain type. class a { abstract public function getNumber() returns int ; } class b extends a { public function getNumber() { return rand() * 3463 ; } } class c extends a { public function getNumber() { return 'I\'m going to mess everything up by returning a string.' ; // Would cause error with type hinting. } } On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
> Hello everyone > > I figured I would bring my opinion in to support of Sam's request for
a more
> complete type hinting feature. Namely I am interested in the support
for
> hinting scalar types on function and method arguments and I am sure it
is
> safe for me to say that I speak for a lot of people. Most people that
I know
> find the current type hinting, while useful, ridiculous because it
looks like
> the job was left unfinished for whatever abstract reason. > > In my opinion type hinting should definitely be allowed for scalar
values. As
> for return types, I am not so sure. So far I have found no use for
such a
> feature in my own code, so I won't comment on it. If it is added, I
welcome
> it for those who find it useful but if it is not added I will not
loose sleep
> over it. > > > I was thinking at something along the lines of objects also for
instance:
> > $i = new Integer(33); > After my own experiments with the subject I concur that while it can
be made
> to work, it is not only a bad idea (for the reasons mentioned earlier)
it is
> also redundant and just unnecessary. There is a lot better way to
accomplish
> the same and that by allowing scalar values to be hinted. It is
simpler,
> cleaner, and easier to implement. > > > What if type hinting just generated an E_NOTICE. Nothing more for
the
> > time being. > Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat
since if I
> write a piece of code that hints that the argument for a-whatever
method
> needs to be an integer it seems useless if the user of my library can
avoid
> the issue just by supressing lesser errors and those who do not need
to write
> extensive error handling code to respond to this sort of error (if
they
> indeed deem it necessary to do so). > > While hinting is, and should remain, optional, when it is used it
should be
> enforced. After all the user of my library has the option to dump it
and go
> for another library that does not force types. That is the beauty of
having
> options. > > Tomi Kaistila > PHP Developer >
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:

Andi Gutmans

18 years ago
We've discussed scalar type hinting many times in the past and decided against it. It really doesn't fit in very well with PHP's loosely typed nature which is one of the main reasons it has been so easy to use. The only reason why it works with classes and arrays is because those are unambiguous constructs. Even this thread shows that there's no alignment between people on what it should actually do. This is due to the lose nature of PHP. For example, HTTP vars come in as strings. So if you have http://localhost/?n=1 in your URL there are some in this thread which would expect it to be successfully juggled by an "int" type hint even though it actually comes in as a string; and some who want it to be ultra-strict and if the PHP type isn't an integer it should emit an error. What happens when you pass an object with a __toString() method to a function expecting a "string"? I think it should work and convert. I am sure some here disagree. This is exactly the problem! Saying that it won't confuse newbies is also wrong. PHP is so popular because it's so easy for people to pick up. Part of this also includes ability to look at other people's code, understand it, copy-on-write (e.g. a Wordpress plug-in). The more features in PHP the harder it'll be for developers to deal with. Yes, we bit the bullet for namespaces because there were strong reasons in favor of it, we as a community had it on our wishlist for a long time and a lot of work went into it. And even when we did it we had to find a way to make it work for PHP. In this case, with the lose typing of PHP creating a consistent model which will be apparent to people without many questions is a big issue. Also, for those who say that when this feature is not used it doesn't have a performance impact that is also a problematic statement. If it exists people will use it. Most people using PHP don't understand (and shouldn't have to understand) how the language is implemented. It may very well be that even if we could agree on the semantics we'll see all sorts of developers "decorate" their code with type hints (because they think it'll help readability) who may down the road find themselves in a surprise when it comes to performance. Last, just because something can be implemented and a patch exists doesn't mean it should be in PHP. There are lots of things I can implement for PHP which shouldn't be in PHP. Also don't under estimate what happens when you get bloatware and over time how much harder it becomes to maintain and also how it does eventually end up slowing things down (over time there are more branches, more code a.k.a more cache misses, etc...) We have what I think is a very exciting PHP version coming up with 5.3. The featureset has been agreed upon. It'd be great if all the contributing energy in this thread could be channeled towards playing around with 5.3 esp. the new i18n extension, namespaces, help with migration/incompatibility notes and garbage collector benchmarks. We are now at the stage where we really need the code base to mature with feedback from users. The more you can invest in that the better. Ouch, sorry for the long email! :'( Andi P.S.- The runtime piece of this patch also looks wrong. I didn't dive deep but those if() statements don't look too friendly.

Tomi Kaistila

18 years ago
> It really doesn't fit in very well with PHP's loosely typed nature which > is one of the main reasons it has been so easy to use.
I think this is one of the cornerstones that two sides disagree the most on. People are afraid that PHP would turn into a strong-typed language by allowing type hinting for scalar values. I do not think this would be the case. You would still have all the freedom that you have no with PHP, since PHP's type juggling is still in effect. The only thing that would change is that the validation of the data that is passed into functions would be somewhat automated, but since the validation occurs with or without type hinting the result is still the same. If data is incorrent, an error occurs whether it is an exception, a false return type, or a triggered error. The behaviour of the program does not change with type hinting.
> Even this thread shows that there's no alignment between people on what > it should actually do.
This is true, but contributed to it is that so far we have spent more time and energy on the silly debate whether or not type hinting is a useful feature. There is enough technical proof to suggest that it is in fact a useful feature. What I would like to see is actual discussion on how it should behave and see if a concensus can be derived.
> Saying that it won't confuse newbies is also wrong. PHP is so popular > because it's so easy for people to pick up. Part of this also includes > ability to look at other people's code, understand it, copy-on-write > (e.g. a Wordpress plug-in).
This is an argument that I honestly do not understand. Type hinting is already here. It exists in PHP. How can the concept be abandoned on the bases that it would confuse new users, if the concept has already been approved and implemented? Tomi Kaistila PHP Developer

Sam Barrow

18 years ago
On Fri, 2008-01-04 at 10:06 +0200, Tomi Kaistila wrote:
> > It really doesn't fit in very well with PHP's loosely typed nature which > > is one of the main reasons it has been so easy to use. > I think this is one of the cornerstones that two sides disagree the most on. > People are afraid that PHP would turn into a strong-typed language by > allowing type hinting for scalar values. I do not think this would be the > case. You would still have all the freedom that you have no with PHP, since > PHP's type juggling is still in effect. > > The only thing that would change is that the validation of the data that is > passed into functions would be somewhat automated, but since the validation > occurs with or without type hinting the result is still the same. If data is > incorrent, an error occurs whether it is an exception, a false return type, > or a triggered error. The behaviour of the program does not change with type > hinting.
Exactly. This is not strict typing. It's type hinting (key word, hinting).
> > Even this thread shows that there's no alignment between people on what > > it should actually do. > This is true, but contributed to it is that so far we have spent more time and > energy on the silly debate whether or not type hinting is a useful feature. > There is enough technical proof to suggest that it is in fact a useful > feature. > > What I would like to see is actual discussion on how it should behave and see > if a concensus can be derived. > > > Saying that it won't confuse newbies is also wrong. PHP is so popular > > because it's so easy for people to pick up. Part of this also includes > > ability to look at other people's code, understand it, copy-on-write > > (e.g. a Wordpress plug-in). > This is an argument that I honestly do not understand. Type hinting is already > here. It exists in PHP. How can the concept be abandoned on the bases that it > would confuse new users, if the concept has already been approved and > implemented? >
Exactly, array and class type hints are actually more confusing than scalar type hints. What's more confusing to a beginner, having to pass an instance of a certain object to a function, or having to pass a number or string?

Sam Barrow

18 years ago
On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
> We've discussed scalar type hinting many times in the past and decided > against it. > It really doesn't fit in very well with PHP's loosely typed nature which > is one of the main reasons it has been so easy to use. The only reason > why it works with classes and arrays is because those are unambiguous > constructs.
It doesn't fit. This is not a technical argument, this is your opinion on the way PHP should be. That's the problem here.
> Even this thread shows that there's no alignment between people on what > it should actually do. This is due to the lose nature of PHP. For > example, HTTP vars come in as strings. So if you have > http://localhost/?n=1 in your URL there are some in this thread which > would expect it to be successfully juggled by an "int" type hint even > though it actually comes in as a string; and some who want it to be > ultra-strict and if the PHP type isn't an integer it should emit an > error. What happens when you pass an object with a __toString() method > to a function expecting a "string"? I think it should work and convert. > I am sure some here disagree. This is exactly the problem!
We keep saying that scalar type hinting is not intended to be used for input. Even so, if you really wanted to you could run your input through a very simple function and convert each variable into the appropriate type. function typeConvert($variable) { if (is_array($variable)) { foreach ($variable as $k => $v) { $variable[$k] = typeConvert($v) ; } } else if (is_object($variable)) { foreach ($variable as $k => $v) { $variable -> $k = typeConvert($v) ; } } else { if (is_numeric($variable) and substr($variable, 0, 1) !== '0') { if (substr_count($variable, '.')) { $variable = (float) $variable ; } else { $variable = (int) $variable ; } } } return $variable ; }
> Saying that it won't confuse newbies is also wrong. PHP is so popular > because it's so easy for people to pick up. Part of this also includes > ability to look at other people's code, understand it, copy-on-write > (e.g. a Wordpress plug-in). The more features in PHP the harder it'll be > for developers to deal with. Yes, we bit the bullet for namespaces > because there were strong reasons in favor of it, we as a community had > it on our wishlist for a long time and a lot of work went into it. And > even when we did it we had to find a way to make it work for PHP. In > this case, with the lose typing of PHP creating a consistent model which > will be apparent to people without many questions is a big issue.
I've said this numerous times too. How hard is it to understand? If someone can't understand this simple concept they are sure as hell not going to understand object oriented or anything. Plus the fact that this is actually easier to understand than array/object type hints.
> Also, for those who say that when this feature is not used it doesn't > have a performance impact that is also a problematic statement. If it > exists people will use it. Most people using PHP don't understand (and > shouldn't have to understand) how the language is implemented. It may > very well be that even if we could agree on the semantics we'll see all > sorts of developers "decorate" their code with type hints (because they > think it'll help readability) who may down the road find themselves in a > surprise when it comes to performance.
Well that's their decision. I could use functions and not use a single class in my applications, and they would be faster. I sacrifice a little performance in order to make my code better.
> Last, just because something can be implemented and a patch exists > doesn't mean it should be in PHP. There are lots of things I can > implement for PHP which shouldn't be in PHP. Also don't under estimate > what happens when you get bloatware and over time how much harder it > becomes to maintain and also how it does eventually end up slowing > things down (over time there are more branches, more code a.k.a more > cache misses, etc...)
You are right here. But define bloatware. Type hinting is already in PHP. All I want to do is add a couple of types to this already implemented feature. My patch is pretty small.
> We have what I think is a very exciting PHP version coming up with 5.3. > The featureset has been agreed upon. It'd be great if all the > contributing energy in this thread could be channeled towards playing > around with 5.3 esp. the new i18n extension, namespaces, help with > migration/incompatibility notes and garbage collector benchmarks. We are > now at the stage where we really need the code base to mature with > feedback from users. The more you can invest in that the better.
Good point, namespaces need to be tested and brought to a production state, and i18n looks pretty interesting.
> Ouch, sorry for the long email! :'( > > Andi > > P.S.- The runtime piece of this patch also looks wrong. I didn't dive > deep but those if() statements don't look too friendly.
It's worked for me fine for a couple of months. The if statements in zend_compile.c are pretty confusing (as far as the brace indentation goes).

Andi Gutmans

18 years ago
See below:
> -----Original Message----- > From: Sam Barrow [mailto:sam@sambarrow.com] > Sent: Friday, January 04, 2008 5:47 AM > To: Andi Gutmans > Cc: internals@lists.php.net > Subject: RE: [PHP-DEV] RE: Optional scalar type hinting > > On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote: > > We've discussed scalar type hinting many times in the past and > decided > > against it. > > It really doesn't fit in very well with PHP's loosely typed nature > which > > is one of the main reasons it has been so easy to use. The only > reason > > why it works with classes and arrays is because those are
unambiguous
> > constructs. > > It doesn't fit. This is not a technical argument, this is your opinion > on the way PHP should be. That's the problem here.
Are you saying that languages are designed only based on technicalities? So why are languages so different? Each language has a spirit and an emphasis and this is definitely something to think about. It also relates to what the applicable market and users are. -snip- So why don't we first see if people can agree on what this does: I think all the following ones should work: function iwantint(int $n) { iwantint("1"); // "1" + 1 works great. function iwantstring(string $str) {} iwantstring($toStringObject); // Works in strcmp() function iwantfloat(float $f) {} iwantfloat(2); function iwantbool(bool $b) {} iwantbool(1); function iwantnull(null $n) {} iwantnull(null); //Does this exist? And for consistency of the language we would be using PHP's type juggling system to see if there's a match or not and you'd get whatever results you get today. Btw I think there's absolutely no argument that the error should be exactly the same as with array/class hints. No way are we going to have two different errors for the same kind of functionality. That's ludicrous. More below:...
> > Saying that it won't confuse newbies is also wrong. PHP is so
popular
> > because it's so easy for people to pick up. Part of this also > includes > > ability to look at other people's code, understand it, copy-on-write > > (e.g. a Wordpress plug-in). The more features in PHP the harder
it'll
> be > > for developers to deal with. Yes, we bit the bullet for namespaces > > because there were strong reasons in favor of it, we as a community > had > > it on our wishlist for a long time and a lot of work went into it. > And > > even when we did it we had to find a way to make it work for PHP. In > > this case, with the lose typing of PHP creating a consistent model > which > > will be apparent to people without many questions is a big issue. > > I've said this numerous times too. How hard is it to understand? If > someone can't understand this simple concept they are sure as hell not > going to understand object oriented or anything.
There are actually a lot of PHP developers who don't do OO oriented. This is why we left it as a choice to developers (it's been around btw since 1997 at least the basic OO functionality). Anyway what's confusing here are the semantics not the feature itself. For example, I expect something different than you do.
> Plus the fact that this is actually easier to understand than > array/object type hints.
I don't think so because there's no potential type juggling in those (which is why we did it) but it's a pointless argument because it doesn't add much value to the discussion.
> > Also, for those who say that when this feature is not used it
doesn't
> > have a performance impact that is also a problematic statement. If
it
> > exists people will use it. Most people using PHP don't understand > (and > > shouldn't have to understand) how the language is implemented. It
may
> > very well be that even if we could agree on the semantics we'll see > all > > sorts of developers "decorate" their code with type hints (because > they > > think it'll help readability) who may down the road find themselves > in a > > surprise when it comes to performance. > > Well that's their decision. I could use functions and not use a single > class in my applications, and they would be faster. I sacrifice a > little > performance in order to make my code better. > > > Last, just because something can be implemented and a patch exists > > doesn't mean it should be in PHP. There are lots of things I can > > implement for PHP which shouldn't be in PHP. Also don't under > estimate > > what happens when you get bloatware and over time how much harder it > > becomes to maintain and also how it does eventually end up slowing > > things down (over time there are more branches, more code a.k.a more > > cache misses, etc...) > > You are right here. But define bloatware. Type hinting is already in > PHP. All I want to do is add a couple of types to this already > implemented feature. My patch is pretty small. >
Small small but the way it is currently implemented I both don't agree with (semantics) and I think it can also be implemented better (for starters I'd use a switch() statement in the runtime piece. I am not too worried about zend_compile.c).
> > P.S.- The runtime piece of this patch also looks wrong. I didn't
dive
> > deep but those if() statements don't look too friendly. > > It's worked for me fine for a couple of months. The if statements in > zend_compile.c are pretty confusing (as far as the brace indentation > goes).
I'm sure it worked fine for you but I don't think I agree with the semantics and I believe implementation could be improved. Andi

Sam Barrow

18 years ago
On Fri, 2008-01-04 at 10:08 -0800, Andi Gutmans wrote:
> See below: > > > -----Original Message----- > > From: Sam Barrow [mailto:sam@sambarrow.com] > > Sent: Friday, January 04, 2008 5:47 AM > > To: Andi Gutmans > > Cc: internals@lists.php.net > > Subject: RE: [PHP-DEV] RE: Optional scalar type hinting > > > > On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote: > > > We've discussed scalar type hinting many times in the past and > > decided > > > against it. > > > It really doesn't fit in very well with PHP's loosely typed nature > > which > > > is one of the main reasons it has been so easy to use. The only > > reason > > > why it works with classes and arrays is because those are > unambiguous > > > constructs. > > > > It doesn't fit. This is not a technical argument, this is your opinion > > on the way PHP should be. That's the problem here. > > Are you saying that languages are designed only based on technicalities? > So why are languages so different? Each language has a spirit and an > emphasis and this is definitely something to think about. It also > relates to what the applicable market and users are.
True. I'm saying that this is being taken too far in this case. PHP with type hinting is still PHP, I am not asking to redesign the entire structure of the language.
> -snip- > > So why don't we first see if people can agree on what this does: > > I think all the following ones should work: > > function iwantint(int $n) { > iwantint("1"); // "1" + 1 works great. > > function iwantstring(string $str) {} > iwantstring($toStringObject); // Works in strcmp() > > function iwantfloat(float $f) {} > iwantfloat(2); > > function iwantbool(bool $b) {} > iwantbool(1); > > function iwantnull(null $n) {} > iwantnull(null); //Does this exist?
Null hint does not exist, as null is only one value and it would be pointless. I've stated my opinion on this, I'm going for standard hinting. Int means int, not "1" or "one" or "1one". Bool means boolean true or false, not "true", 1, 0, "0", etc.
> > And for consistency of the language we would be using PHP's type > juggling system to see if there's a match or not and you'd get whatever > results you get today. > > Btw I think there's absolutely no argument that the error should be > exactly the same as with array/class hints. No way are we going to have > two different errors for the same kind of functionality. That's > ludicrous.
Errors should all be the same for any type hint.
> More below:... > > > > Saying that it won't confuse newbies is also wrong. PHP is so > popular > > > because it's so easy for people to pick up. Part of this also > > includes > > > ability to look at other people's code, understand it, copy-on-write > > > (e.g. a Wordpress plug-in). The more features in PHP the harder > it'll > > be > > > for developers to deal with. Yes, we bit the bullet for namespaces > > > because there were strong reasons in favor of it, we as a community > > had > > > it on our wishlist for a long time and a lot of work went into it. > > And > > > even when we did it we had to find a way to make it work for PHP. In > > > this case, with the lose typing of PHP creating a consistent model > > which > > > will be apparent to people without many questions is a big issue. > > > > I've said this numerous times too. How hard is it to understand? If > > someone can't understand this simple concept they are sure as hell not > > going to understand object oriented or anything. > > There are actually a lot of PHP developers who don't do OO oriented. > This is why we left it as a choice to developers (it's been around btw > since 1997 at least the basic OO functionality).
OK. And they're not using OO right? So tell them not to use type hinting either!
> Anyway what's confusing here are the semantics not the feature itself. > For example, I expect something different than you do. > > > Plus the fact that this is actually easier to understand than > > array/object type hints. > > I don't think so because there's no potential type juggling in those > (which is why we did it) but it's a pointless argument because it > doesn't add much value to the discussion.
You have a point, but it is still a very simple concept.
> > > Also, for those who say that when this feature is not used it > doesn't > > > have a performance impact that is also a problematic statement. If > it > > > exists people will use it. Most people using PHP don't understand > > (and > > > shouldn't have to understand) how the language is implemented. It > may > > > very well be that even if we could agree on the semantics we'll see > > all > > > sorts of developers "decorate" their code with type hints (because > > they > > > think it'll help readability) who may down the road find themselves > > in a > > > surprise when it comes to performance. > > > > Well that's their decision. I could use functions and not use a single > > class in my applications, and they would be faster. I sacrifice a > > little > > performance in order to make my code better. > > > > > Last, just because something can be implemented and a patch exists > > > doesn't mean it should be in PHP. There are lots of things I can > > > implement for PHP which shouldn't be in PHP. Also don't under > > estimate > > > what happens when you get bloatware and over time how much harder it > > > becomes to maintain and also how it does eventually end up slowing > > > things down (over time there are more branches, more code a.k.a more > > > cache misses, etc...) > > > > You are right here. But define bloatware. Type hinting is already in > > PHP. All I want to do is add a couple of types to this already > > implemented feature. My patch is pretty small. > > > > Small small but the way it is currently implemented I both don't agree > with (semantics) and I think it can also be implemented better (for > starters I'd use a switch() statement in the runtime piece. I am not too > worried about zend_compile.c). > > > P.S.- The runtime piece of this patch also looks wrong. I didn't > dive > > > deep but those if() statements don't look too friendly. > > > > It's worked for me fine for a couple of months. The if statements in > > zend_compile.c are pretty confusing (as far as the brace indentation > > goes). > > I'm sure it worked fine for you but I don't think I agree with the > semantics and I believe implementation could be improved.
Semantics can be changed, my only goal is to enable scalar type hinting in PHP. Implementation is a small issue. I have no problem fixing up my code to the community's liking.

Stanislav Malyshev

18 years ago
> I've stated my opinion on this, I'm going for standard hinting. Int > means int, not "1" or "one" or "1one". Bool means boolean true or false,
I don't see any difference in substance between 1 and "1".
> not "true", 1, 0, "0", etc.
Same for boolean - I don't see any substantial difference between (int)0, (float)0 and (boolean)false and see no reason ever to make a function that distinguishes between those. Now, statically-typed compiled languages do it for the very good reason - it is very hard to implement such versatile API manually. It is infeasible to make all C function declared as foo(int i) to take char* instead and use atoi() or whatever it needs to be - and do it for each and every function. That's exactly why scripting languages with loose typing were created - to allow programmers to get rid of these technicalities and work with substance of the values, not with bit representation of them. Now you come back and say - no, my function would accept (boolean)0 but would pretend it can not handle (int)0 because the bits in a type field of the variable are wrong. What could be the practical purpose of such dumbing-down? Getting all the stress of the programming in statically typed language without compile-time checking and safety as a compensation for the stress? Doesn't look as a good deal for me.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com