Re: [PHP-DEV] Re: Flexible type hinting
On 03.07.2009, at 15:04, Paul Biggar wrote: Since this can be built as an extra step on top of your patch, this can be added later (although it would obviously be great if you preferred to add it now...). I recommend you proceed with the next step of getting your patch accepted (I presume an RFC or something). Going by Ilia's comments about RFC's on IRC, I guess someone else should take on writing an RFC, summarizing the discussion, linking important ml posts and moving forward with a vote, keeping in account the various relevant options/variations suggested. This RFC here can serve as a starting point: http://wiki.php.net/rfc/typehint Remember anyone can request a wiki account and do this. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ford, Mike wrote: function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). I had thought about having "weak" and "strong' type checking even before Paul sent his proposal, but I rejected the idea myself for the confusion it might cause because I couln't think of a good syntax. This one actually looks pretty good, it's intuitive and consistent with what the language offers now. Big +1 regards Rodrigo Saboya -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi Lukas, On Fri, Jul 3, 2009 at 2:35 PM, Lukas Kahwe Smith wrote: > hmm not sure that the consensus of a "weak" check would be an automatic > cast. Actually that wouldnt be much of a check in that case. I think the > other side is more asking for what Ilia already begun with "numeric" in the > sense of a weak checker. After the check it could go ahead and cast too for > all I care, but it shouldnt be the equivalent of a cast. But maybe you are > not implying that and I am just getting confused by the syntax. I think people wanted an automatic cast for the weak check. The idea would be that if you hinted "(int)", you could be guaranteed that you got an int. The syntax was suggested (I believe, it wasn't my suggestion) to look like casting. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 03.07.2009, at 15:04, Paul Biggar wrote:
Hi Ilia,
On Thu, Jul 2, 2009 at 3:35 AM, Paul Biggar
wrote:
Thanks to Ilia for getting to ball rolling on scalar type hinting.
I believe I have a solution that caters to each crowd, without being
too complicated.
My impression is that there only minor support for the "flexible"
approach, and that even then, everyone prefers strict checking by
default. So the ideal seems to be your patch, with the addition of
function x ((int) $casted_parameter) { ... }
hmm not sure that the consensus of a "weak" check would be an
automatic cast. Actually that wouldnt be much of a check in that case.
I think the other side is more asking for what Ilia already begun with
"numeric" in the sense of a weak checker. After the check it could go
ahead and cast too for all I care, but it shouldnt be the equivalent
of a cast. But maybe you are not implying that and I am just getting
confused by the syntax.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
Hi Ilia,
On Thu, Jul 2, 2009 at 3:35 AM, Paul Biggar wrote:
> Thanks to Ilia for getting to ball rolling on scalar type hinting.
> I believe I have a solution that caters to each crowd, without being
> too complicated.
My impression is that there only minor support for the "flexible"
approach, and that even then, everyone prefers strict checking by
default. So the ideal seems to be your patch, with the addition of
function x ((int) $casted_parameter) { ... }
Since this can be built as an extra step on top of your patch, this
can be added later (although it would obviously be great if you
preferred to add it now...). I recommend you proceed with the next
step of getting your patch accepted (I presume an RFC or something).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
2009/7/2 Stanislav Malyshev : > Hi! > >> function func(int $i) >> >> for strict type checking, and >> >> function func((int)$i) > > Without saying anything on the merits of having both syntaxes, visually I > think this looks much nicer, even with the disadvantage of parentheses > overload. Oh look, auto-casting. And __cast() is excellent, but would be at odds with __toString(). And then having __toBoolean(), __toInteger(), etc. might be a bit OTT. How about __cast($type [,$class]) where $type is one of the T_xxx_CAST constants and class is the required class for a class casting? (See nearly already there!) T_ARRAY_CAST T_BOOL_CAST T_DOUBLE_CAST T_INT_CAST T_OBJECT_CAST T_STRING_CAST -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
this one looks much more intuitive. Tyrael 2009/7/2 Ford, Mike : > > >> -Original Message- >> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] >> Sent: 02 July 2009 14:05 >> To: Ilia Alshanetsky >> Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev; >> Hannes Magnusson >> Subject: Re: [PHP-DEV] Re: Flexible type hinting >> >> >> On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: >> >> > Personally, I am uncertain about +int or -int in general, IMO that >> > compromise will eventually be identical to numeric an cause >> endless >> > confusion for the users between (+/-)int and int. The reason I >> used >> > a completely different name is to prevent confusion. >> >> >> I do not see the risk for confusion as being high. >> Like I said, I havent made up my mind on this proposal, however for >> now Paul mainly asked for feedback in the general concept, not >> necessarily on the syntax. > > Interesting discussion. Not sure where I stand on this one, but I > definitely don't like the [+-]int syntax. Even before Paul's proposal > came out, though, I was thinking that I'd want to consider leveraging an > existing well-understood syntax, so I could write > > function func(int $i) > > for strict type checking, and > > function func((int)$i) > > for coercion aka casting (although now I've seen it written down I'm not > so sure! ;). > > I don't see the need for another option beyond the current > syntax/behaviour -- in my opinion, anything else is documentation and > should be treated as such. > > > Cheers! > > Mike > > -- > Mike Ford, Electronic Information Developer, > C507, Leeds Metropolitan University, Civic Quarter Campus, > Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom > Email: m.f...@leedsmet.ac.uk > Tel: +44 113 812 4730 > > > > To view the terms under which this email is distributed, please go to > http://disclaimer.leedsmet.ac.uk/email.htm > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 9:09 PM, Ryan Panning wrote: > Ford, Mike wrote: > >>function func(int $i) >> >> for strict type checking, and >> >>function func((int)$i) >> >> for coercion aka casting (although now I've seen it written down I'm not >> so sure! ;). >> > > Just want to throw my 2 cents in. > > Big +1 for this syntax > > I think with the addition of this and __cast() for objects, PHP's OO will > be very flexible and can build great Frameworks, ORM's, etc. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > function($quantity) function(int $quantity) STRICT type function(?int $quantity) Thought id throw it out there. Interesting discussion though. Ólafur
Re: [PHP-DEV] Re: Flexible type hinting
Ford, Mike wrote: function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). Just want to throw my 2 cents in. Big +1 for this syntax I think with the addition of this and __cast() for objects, PHP's OO will be very flexible and can build great Frameworks, ORM's, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi 2009/7/2 Stanislav Malyshev : > Without saying anything on the merits of having both syntaxes, visually I > think this looks much nicer, even with the disadvantage of parentheses > overload. I agree, using the type cast operators for casting to the type, and non parentheses for strict checking isnt such a bad idea actually. It even makes sense without knowing the difference almost ;) -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi! function func(int $i) for strict type checking, and function func((int)$i) Without saying anything on the merits of having both syntaxes, visually I think this looks much nicer, even with the disadvantage of parentheses overload. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Flexible type hinting
> -Original Message- > From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] > Sent: 02 July 2009 14:05 > To: Ilia Alshanetsky > Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev; > Hannes Magnusson > Subject: Re: [PHP-DEV] Re: Flexible type hinting > > > On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: > > > Personally, I am uncertain about +int or -int in general, IMO that > > compromise will eventually be identical to numeric an cause > endless > > confusion for the users between (+/-)int and int. The reason I > used > > a completely different name is to prevent confusion. > > > I do not see the risk for confusion as being high. > Like I said, I havent made up my mind on this proposal, however for > now Paul mainly asked for feedback in the general concept, not > necessarily on the syntax. Interesting discussion. Not sure where I stand on this one, but I definitely don't like the [+-]int syntax. Even before Paul's proposal came out, though, I was thinking that I'd want to consider leveraging an existing well-understood syntax, so I could write function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). I don't see the need for another option beyond the current syntax/behaviour -- in my opinion, anything else is documentation and should be treated as such. Cheers! Mike -- Mike Ford, Electronic Information Developer, C507, Leeds Metropolitan University, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi! Are optional argument specifications inherited? I did not think they were, but its not clear if you are saying they are. Of course they are - how couldn't they be, they are part of method definition. My understanding of PHP's optional arguments is that they only apply to a function once it is called. Yes, but it doesn't prevent them from being part of inheritance logic. if you have foo($a = 1) then you can't override it with foo($a) - it violates LSP (imagine somebody calling $a->foo()). And it is doing something - if you declare interface as foo(int $a) and implement it as foo(string $a) there may be a lot of WTF happening. I mean that it is never called, therefore the type hints are not checked, and this is fine. But it is called! The whole point of the interface is to call it - i.e. to have code use the fact that you can be sure to have foo(int $a) in some object of some unknown class. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
2009/7/2 Paul Biggar > On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron > wrote: > > From userland, I'm a big fan of this proposal / agree to the principle > although I'm not convinced that > > > > function($quantity) > > function(int $quantity) > > function(+int $quantity) > > function(-int $quantity) > > > > looks appropriate... > > > > Userland Note: The "-int" semantics confuses me, I realize it would cast > null's etc... but is it really a requirement? Can it be dropped? > > Yes, it looks off, doesnt it. I quite like ~int, which you suggested > below, for the casting. It makes me think "this is kinda an int". > > > > function($quantity) > > function(int $quantity) paul's (S) casting > > function(int! $quantity) STRICT type --- seems appropriate for php, > follows CSS/web style '!important' > > Yes, I like that too. > But the exclamation mark has previous use in conditionals, so it may be confused with "anything but an int" Lewis.
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron wrote: > From userland, I'm a big fan of this proposal / agree to the principle > although I'm not convinced that > > function($quantity) > function(int $quantity) > function(+int $quantity) > function(-int $quantity) > > looks appropriate... > > Userland Note: The "-int" semantics confuses me, I realize it would cast > null's etc... but is it really a requirement? Can it be dropped? Yes, it looks off, doesnt it. I quite like ~int, which you suggested below, for the casting. It makes me think "this is kinda an int". > function($quantity) > function(int $quantity) paul's (S) casting > function(int! $quantity) STRICT type --- seems appropriate for php, follows > CSS/web style '!important' Yes, I like that too. > To me, strict as default doesn't seem appropriate in php. But if it does, > this syntax could be interesting: > > function($quantity) > function(int $quantity) STRICT type > function(~int $quantity) paul's (S) casting This is also a nice, internally-consistent syntax. If you had something for (H) in your suggestions, I'd be happier. We need to cast there too. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Flexible type hinting
On Thu Jul 2 08:53 AM, Paul Biggar wrote: > On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote: > > > > On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: > >> I think you might not have read what I suggested (it is different > >> than the one I emailed to you privately). What you want is fully > supported. > >> If you must be passed an int, use the +int hint. > > > > I'd rather use -int, then +int and make people who want loose typing > > do the extra bit, because native typing should be strict. > > I think everyone wants their favourite to be default. I was eager to > have the typing that's currently in the manual be the default, since > that's what people are used to seeing. I suggested that strong type > checks use +int exactly because that's different to what's in the > manual, so there would be no confusion. > > I'm really looking to get people to agree to the principle that we > would like to be able to hint every signature without large changes to > the manual, since we've been looking at it for years. > >From userland, I'm a big fan of this proposal / agree to the principle >although I'm not convinced that function($quantity) function(int $quantity) function(+int $quantity) function(-int $quantity) looks appropriate... Userland Note: The "-int" semantics confuses me, I realize it would cast null's etc... but is it really a requirement? Can it be dropped? function($quantity) function(int $quantity) paul's (S) casting function(int! $quantity) STRICT type --- seems appropriate for php, follows CSS/web style '!important' To me, strict as default doesn't seem appropriate in php. But if it does, this syntax could be interesting: function($quantity) function(int $quantity) STRICT type function(~int $quantity) paul's (S) casting Btw, really interesting discussions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 10:02 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. No, the idea of type hinting is that you hint to the user about what type the interface expects. You have implemented "strong type checking" instead. I wonder that you cannot see the conflict between the term "type hinting" and "strict interfaces". I would be happier if you renamed your patch "optional strong scalar type checking", which is what it is. That's a fair statement I suppose. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetsky wrote: > Paul's proposal is some part does not make sense because it allows weak type > hinting, which should not be used if you need type hinting. The whole idea > about type hinting is definition of strict interfaces, not loosely based > one. That's just my opinion, which admittedly I feel fairly strongly about. No, the idea of type hinting is that you hint to the user about what type the interface expects. You have implemented "strong type checking" instead. I wonder that you cannot see the conflict between the term "type hinting" and "strict interfaces". I would be happier if you renamed your patch "optional strong scalar type checking", which is what it is. I have described a system that allows "strong type checking", "type hinting", and "type casting", which I think is all the use cases. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ilia Alshanetsky wrote: On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ilia Alshanetsky wrote: On 2-Jul-09, at 9:23 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. It is not about what PHP can convert, in the past and if you use old function parameter parsing api PHP will even convert arrays to strings. Its about delivering to the function/method exactly what it wants and not a close facsimile thereof. That's why I said, instead of E_RECOVERABLE it should be an E_WARNING with type coercion to what the hint requested. The function gets what it wants, and the developer gets a warning that it wasn't quite what it expected. Run time code doesn't just die because I've upgraded an application and missed a single API call update to comply with primitive type hinting. That's annoying in a production environment, and since it's run-time fail, it's not necessarily easy to catch all the issues. There *will* be production systems dying due to missed updates. There's the suggestion to capture the E_RECOVERABLE error, but that's putting the onus on developers and non-developers installing applications to have this in place, and due to the run-time nature of the problem, *everyone* would be better off putting it in place, just in case their production system goes down. Since 99% of coercions of primitive types are fine, I don't see why the majority must suffer the problem when the minority will be perfectly served by an E_WARNING to correct their code. You mentioned in your environment you've been using this for a while now and found problems otherwise very difficult to find. These same problems would also have been detected with an E_WARNING with the added value of the application not dying (or do you already have that E_RECOVERABLE handler in place). Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 9:23 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. It is not about what PHP can convert, in the past and if you use old function parameter parsing api PHP will even convert arrays to stirngs. Its about delivering to the function/method exactly what it wants and not a close facsimile thereof. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Have you using existing array or class type hinting? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: Personally, I am uncertain about +int or -int in general, IMO that compromise will eventually be identical to numeric an cause endless confusion for the users between (+/-)int and int. The reason I used a completely different name is to prevent confusion. I do not see the risk for confusion as being high. Like I said, I havent made up my mind on this proposal, however for now Paul mainly asked for feedback in the general concept, not necessarily on the syntax. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Ilia Alshanetsky wrote: Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
Personally, I am uncertain about +int or -int in general, IMO that compromise will eventually be identical to numeric an cause endless confusion for the users between (+/-)int and int. The reason I used a completely different name is to prevent confusion. On 2-Jul-09, at 8:53 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote: On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. I'd rather use -int, then +int and make people who want loose typing do the extra bit, because native typing should be strict. I think everyone wants their favourite to be default. I was eager to have the typing that's currently in the manual be the default, since that's what people are used to seeing. I suggested that strong type checks use +int exactly because that's different to what's in the manual, so there would be no confusion. I'm really looking to get people to agree to the principle that we would like to be able to hint every signature without large changes to the manual, since we've been looking at it for years. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 4:56 AM, Lukas Kahwe Smith wrote: On 02.07.2009, at 10:45, Paul Biggar wrote: to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. I think he is replying to me here. I am worried that with Ilia's proposal, people will strictly type everything, even where weakly typed would suffice. The reason being that developers are lazy. With these type "hints" (they are not actually hints, but "checks" as you already made clear), they can very easily move the burden of type juggeling explicitly to the user of their code. At least in my world, I use a lot of 3rd party libraries, which will then likely become essentially strictly typed. While strictly typing can prevent bugs and all sorts of good stuff, we should be more hesitant when it comes to giving people tools that make it easy (encourage) to turn a core principle of PHP upside down. First of all PHP is a tool, if some developers choose(!!) to adopt stricter practices (which I doubt will happen), then perhaps its time for the tool to change with them. As far as I know PHP is there to solve problems and make it easy to do so, not support/enforce certain programming paradigms. I know that "numeric" was a concession to people with my concern from the last discussion. But it doesnt cover all the bases of types. In that vain Paul's proposal does indeed provide a syntax that at least enables both approaches. More importantly it proposes a syntax that requires the same number of characters for both approaches. You might laugh at this comment, but I believe that the overuse of "private" that I am seeing has a lot to do with the fact that its shorter than "protected". Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote: > > On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: >> I think you might not have read what I suggested (it is different than >> the one I emailed to you privately). What you want is fully supported. >> If you must be passed an int, use the +int hint. > > I'd rather use -int, then +int and make people who want loose typing do the > extra bit, because native typing should be strict. I think everyone wants their favourite to be default. I was eager to have the typing that's currently in the manual be the default, since that's what people are used to seeing. I suggested that strong type checks use +int exactly because that's different to what's in the manual, so there would be no confusion. I'm really looking to get people to agree to the principle that we would like to be able to hint every signature without large changes to the manual, since we've been looking at it for years. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 4:45 AM, Paul Biggar wrote: On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetsky wrote: 1) Strict type hinting helps to solve bugs, both the ones made out of careless/missing validation as well as subtle logic bugs that often take hours to resolve. I can tell you that within a week of implementing type hints we've been able to identify 30-40 bugs within a period of day. Many of which would not have been detected with "flexible" type hints that Paul is suggesting here is one example: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. I'd rather use -int, then +int and make people who want loose typing do the extra bit, because native typing should be strict. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On 2-Jul-09, at 3:28 AM, Stanislav Malyshev wrote: Hi! 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external The problem here is that if you want to write a robust code that wouldn't randomly fail at runtime "typically" isn't good enough If it fails it means some funciton did not return the expected value and that's a problem, not something that should be ignored if you decided (if you don't want to use, then things remain as they are) to use type hinting. - since wrong type is supposed to be a fatal error (which one could not handle in the typehinted library code since it happens on the client side before your code takes control), you would want to ensure that would never happen when you call a typedhinted function. And there's only two ways to do it - either make absolutely all functions and variables that interact with typehinted functions to be strict-typed (which we don't plan do) or do casts on each call to hinted function. I do not see how anything else could produce robust code provided that type mismatch is a fatal error and variables can not carry type. "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want Being a C programmer for... hmm... about 20 years now I think I don't have too much problem with strictly typed languages :) I just think doing it in PHP the way you want to do it is going to produce a lot of issues that people tend to under-appreciate when they cheer the new cool feature. Also, looking at the patch I think it doesn't cover the matter of inheriting the typehinted methods - i.e. if there's a typehinted method, could I override it with non-typehinted version or vice versa? What about typehinted interfaces? Which is fine, because some people can use that functionality to overload methods they don't want to be type hinted from external libs the may be using. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
I'm an advocate for introducing optional type hinting as I write many
assert('is_*($foo)') a day.
On Thu, Jul 2, 2009 at 9:28 AM, Stanislav Malyshev wrote:
> And there's only two ways to do it - either make absolutely all functions
> and variables that interact with typehinted functions to be strict-typed
> (which we don't plan do) or do casts on each call to hinted function. I do
> not see how anything else could produce robust code provided that type
> mismatch is a fatal error and variables can not carry type.
In an application not all layers have to deal with arbitrary parameters,
only the layer with user input does. Do I write a (Traversable) cast before
passing an object to foreach()? No, because the object is not user input. My
application will parse POST, GET, COOKIE parameters in layer 1 and call the
underlying layer 2 with the right data type; down from the layer 2 to 4, 5,
10 layer I can use type hinting.
Type hints became part of the contract of layer N: if there is a runtime
error the problem is in layer N-1 not respecting the contract.
function generate_numbers(int $maximum)
{
return .
}
function presentation_layer_display_numbers($input) {
if (isset($input['max']) and is_numeric($input['max'])) {
foreach (generate_numbers($input['max']) as $i) {
echo "$i";
}
} else {
echo $formCodeWithHighlightedErrors;
}
}
presentation_layer_display_numbers($_POST);
Validating input it's something we should already do, but the other parts of
the code can use type hinting. If I really pass a type that is not right to
generate_numbers(), it will be a very bad thing because the function will
not know how to recover; and it should not do: it's a job for the top layer.
Also, looking at the patch I think it doesn't cover the matter of inheriting
> the typehinted methods - i.e. if there's a typehinted method, could I
> override it with non-typehinted version or vice versa? What about typehinted
> interfaces?
For the Liskov Substitution Principle if B extends A you should be able to
call B as if it were A. So typehinted methods should be overriden respecting
the typehint to allow polymorphism.
interface Calculator
{
public function sum(int $a, int $b);
}
class ScientificCalculator
{
public function sum(int $a, int $b);
}
class BrokenCalculator
{
public function sum(int $a, string $b); // some error is thrown
}
class AnotherBrokenCalculator
{
public function sum(int $a, $b); // some error is thrown
}
--
Giorgio Sironi
Piccolo Principe & Ossigeno Scripter
http://ossigeno.sourceforge.net
Re: [PHP-DEV] Re: Flexible type hinting
On 02.07.2009, at 10:45, Paul Biggar wrote: to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. I think he is replying to me here. I am worried that with Ilia's proposal, people will strictly type everything, even where weakly typed would suffice. The reason being that developers are lazy. With these type "hints" (they are not actually hints, but "checks" as you already made clear), they can very easily move the burden of type juggeling explicitly to the user of their code. At least in my world, I use a lot of 3rd party libraries, which will then likely become essentially strictly typed. While strictly typing can prevent bugs and all sorts of good stuff, we should be more hesitant when it comes to giving people tools that make it easy (encourage) to turn a core principle of PHP upside down. I know that "numeric" was a concession to people with my concern from the last discussion. But it doesnt cover all the bases of types. In that vain Paul's proposal does indeed provide a syntax that at least enables both approaches. More importantly it proposes a syntax that requires the same number of characters for both approaches. You might laugh at this comment, but I believe that the overuse of "private" that I am seeing has a lot to do with the fact that its shorter than "protected". I have not really made up my mind about Paul's proposal, but I just wanted to make the above points. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetsky wrote: > 1) Strict type hinting helps to solve bugs, both the ones made out of > careless/missing validation as well as subtle logic bugs that often take > hours to resolve. I can tell you that within a week of implementing type > hints we've been able to identify 30-40 bugs within a period of day. Many of > which would not have been detected with "flexible" type hints that Paul is > suggesting here is one example: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. > type. The code also includes bits from PEAR and external libs like fpdf and > guess what those have no type hints and they work along side with type > hinted code without any issues. It is instructive that PEAR could not use your proposed hints. The "flexible" system would work fine though. > situations. Of all the replies I see no objection so far and the only > complaint (funnily enough) is about existence of IS_NUMERIC. Yes. Nobody wants numeric. It doesnt hint at anything. > I do not wish to start a flame war or arrive at a wishy washy compromise > that does not provide a solid solution. If the majority disagrees with the I think my "flexible" system is not a wishy washy compromise (the one I sent you by private email was). I think rather it has all the advantages you want, all the advantages I want, and even supports what Stas wants. > to work in a future with a library/framework that is strict about its input > or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. Please, take a read over my full proposal. I think you'll find it that it supports everyone's features without compromise. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 9:27 AM, Stanislav Malyshev wrote: > There is a functionality handling default values (or, more precisely, > optional arguments) with inheritance, etc. Are optional argument specifications inherited? I did not think they were, but its not clear if you are saying they are. My understanding of PHP's optional arguments is that they only apply to a function once it is called. > And it is doing something - if > you declare interface as foo(int $a) and implement it as foo(string $a) > there may be a lot of WTF happening. I mean that it is never called, therefore the type hints are not checked, and this is fine. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi! I don't think we need to worry about this. Consider it to be the same as default values. So yes, yes, allowed but dont do anything since those functions are never called. There is a functionality handling default values (or, more precisely, optional arguments) with inheritance, etc. And it is doing something - if you declare interface as foo(int $a) and implement it as foo(string $a) there may be a lot of WTF happening. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On Thu, Jul 2, 2009 at 8:28 AM, Stanislav Malyshev wrote: > Also, looking at the patch I think it doesn't cover the matter of inheriting > the typehinted methods - i.e. if there's a typehinted method, could I > override it with non-typehinted version or vice versa? What about typehinted > interfaces? I don't think we need to worry about this. Consider it to be the same as default values. So yes, yes, allowed but dont do anything since those functions are never called. Paul > -- > Stanislav Malyshev, Zend Software Architect > s...@zend.com http://www.zend.com/ > (408)253-8829 MSN: s...@zend.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
Hi! 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external The problem here is that if you want to write a robust code that wouldn't randomly fail at runtime "typically" isn't good enough - since wrong type is supposed to be a fatal error (which one could not handle in the typehinted library code since it happens on the client side before your code takes control), you would want to ensure that would never happen when you call a typedhinted function. And there's only two ways to do it - either make absolutely all functions and variables that interact with typehinted functions to be strict-typed (which we don't plan do) or do casts on each call to hinted function. I do not see how anything else could produce robust code provided that type mismatch is a fatal error and variables can not carry type. "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want Being a C programmer for... hmm... about 20 years now I think I don't have too much problem with strictly typed languages :) I just think doing it in PHP the way you want to do it is going to produce a lot of issues that people tend to under-appreciate when they cheer the new cool feature. Also, looking at the patch I think it doesn't cover the matter of inheriting the typehinted methods - i.e. if there's a typehinted method, could I override it with non-typehinted version or vice versa? What about typehinted interfaces? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On 1-Jul-09, at 10:35 PM, Paul Biggar wrote: - A strong argument against (C) is that this currently has no parallel with how scalars are handled in PHP currently. It does not need to have a parallel. PHP as a rule is a type flexible language, my intention is not to change that, simply provide developers with yet another tool they can use to make their life easier and not break anything for people who already use PHP and don't want/need type hinting. The way current internal functions handle input should not change, since doing so will break nearly all existing code. We can provide means for authors as Hannes had pointed our earlier, of new extensions and if we choose to allow it internal methods/functions to have script type hints, but IMHO that only makes sense for future code. - An argument for (H)/(S) is that the manual has been written in this style, using this syntax. Manual has nothing to do with this, manual describes native(!!) PHP functions that should not implement type hints unless we as a team all decide to make PHP type strict, which I don't think is such a good idea. - The (C) crowd suggested numeric and scalar to the (H) crowd, but I dont think they were impressed. If you don't use numeric type for native PHP functions you will break lots of existing code. Remember the goal of this excursive is not to change the nature of PHP, but rather provide a non-destructive feature for people who see the benefit in type hinting within their own code. - I dont think there is a strong case for a strongly typed bool. If function returns -1 on error bool cast will convert it to true, which may not be intent. Look guys, I have been using type hints for quite a long time in PHP, something I doubt most developers here can say. It does not mean people should agree with me or implies that what I say is right, but give the following a bit of consideration before listing your objects. 1) Strict type hinting helps to solve bugs, both the ones made out of careless/missing validation as well as subtle logic bugs that often take hours to resolve. I can tell you that within a week of implementing type hints we've been able to identify 30-40 bugs within a period of day. Many of which would not have been detected with "flexible" type hints that Paul is suggesting here is one example: A developer was doing "select * from table" and then using PDO fetchColumn(), on the dev environment table structure was such as the 1st column was a numeric primary key and all worked well. However, in production the order of columns was different and the returned value was actually a login name (varchar), since they happened to be numeric in nature code worked but operated on the wrong ids. It was a very subtle bug that strict type hinting identified instantly and probably saved at least hour's worth of code review. 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external libs like fpdf and guess what those have no type hints and they work along side with type hinted code without any issues. Why? Well, when developers intend to return an int or a float or a boolean, they rarely convert to a string just because they can. 3) Lets not forget that PHP has always been about giving as many tools as possible to our users to help them solve various problems. When I decided to post this patch on this list, thanks largely to encouragement of fellow developers, I've also thrown it on my blog to see what users of PHP think and see if perhaps my specific use case is not applicable in common situations. Of all the replies I see no objection so far and the only complaint (funnily enough) is about existence of IS_NUMERIC. I do not wish to start a flame war or arrive at a wishy washy compromise that does not provide a solid solution. If the majority disagrees with the idea, that's perfectly fine, no harm no foul, I'll keep patching my PHP locally and if I have time maintain a type hinting patch outside of "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want to avoid having to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
