> -----Oorspronkelijk bericht----- > Van: Zeev Suraski [mailto:z...@zend.com] > Verzonden: donderdag 9 juli 2009 11:46 > Aan: Paul Biggar > CC: internals@lists.php.net > Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion > > At 11:39 09/07/2009, Paul Biggar wrote: > >I believe nearly all opinions voiced have wanted the current patch. > >Many more were in favour of strict typing only, but for the few > >dissenters, like myself, Ilia included casting semantics using (int) > >syntax. > > I think that many of the people who expressed > support for that patch did not fully realize its > implications - much in the same way they weren't > quite realizing they're actually voting for > inclusion in PHP 5.3. I believe that if we had a > 'clean' Weak typing RFC as well as a Strict > typing RFC, each with its pros and cons - there > would be very different results. > > >There are I think maybe 5 or 6 people who have expressed opinions > >against this. All others have been pro (I'm not counting the vote > >here, I'm looking at discussions). > > I think you're right, but I also think it had to > do with dynamics more than with actual content. > The two approaches were never compared > head-to-head, with the pros and cons - and more > importantly - with use cases on why strict typing > is necessary despite the fact it's fairly 'alien' to PHP. > > > > 2. Â Make sure people understand *why* we're > > implementing it - performance is > > > certainly *not* the reason. > > > >I believe there was only two misguided souls who believed this would > >lead to better performance. Everyone else wanted it on its merits. > > Maybe - but the only way to make sure is to make it a clear part of the > RFC(s). > > >It doesnt sound like you are aware of the casting semantics that Ilia > >added. They are largely consistent with the internal function > >semantics. > > > >function x (int x) { /* fail on non-int */ } > >function x ((int) x) { /* cast parameter to an int */ } // just like > >internals functions > > I am - and I think I like this even less than > pure strict typing because of increased WTF factor. > I think strict typing is wrong for PHP, and this > cannot be fixed by also adding something > else. The way to 'fix' this is by not adding > strict typing, and adding only weak typing. > > >Indeed this adds the ability to make your function work like an > >internals function (useful perhaps for library interfaces). > > If improved with slightly more intrusive checks > (like the ones suggested in my email) - then it > can be useful in mostly all of the places where strict typing would be > used. > > > > I think we can take Lukas's RFC and either change it or write > something > > > based on it for weak typing only. Â If people here find it useful > I'll go > > > ahead and do that. > > > >I believe people don't want this. I wrote a set of rules, Lukas wrote > >the RFC, and neither got anything like the support that strict typing > >got. > > This could be for a variety of reasons - one of > them is that people truly thought this through > and truly prefer strict typing to weak > typing. But that is just one of the > options. Another is that the difference between > the two approaches, as well as the issues with > strict typing - aren't fully understood by the > audience - and I believe that this is actually the case. > > >One large problem is that it introduced a new 3rd set of rules, and > >this set is not intuitive but rather slightly subjective (reasonable > >people might disagree on whether a bool should be weakly converted to > >an int, for example). The strict type checks are at least simple, and > >the current weak ones are what people are used to. > > I definitely don't think we should add two new > semantics. Ideally we shouldn't add any > entirely-new semantics, and what I'm proposing is > to actually reuse the existing semantics for > internal functions - with very minor > modifications. Kind of like Semantics and > Semantics', rather than Sematnics1, Semantics2, Semantics3. > > >Obviously I'm not against discussion, but we just had this discussion. > > Given the implications of introducing something > like that (that can easily grow in the future to > other parts of PHP) - and my belief that the > discussion missed key ingredients, we should discuss it further. > > We need to go back to the fundamentals - and look > for use cases where strict typing would be > substantially superior to weak typing. As far as > reflection, code readability, optimization and > security is concerned - I can't find any > superiority, but maybe I'm missing something. We > already have an RFC that details the > disadvantages of strict typing (Lukas's > RFC). Let's focus on the advantages and see if they're worth it? > > Zeev >
I am a long time (passive) list reader but seeing the direction of this discussion makes me feel obligated to express my opinion. I'm a framework developer and I have great interest in type hinting/casting. I'm all for clarity and strictness, but it should definitely be a choice. PHP is known for its easy learning curve, that is one of its big powers and that should remain unchanged. But the way I see it is that it can be implemented without *requiring* you to use it, if you want to use type hinting/casting go ahead, if you don't want it, well, leave that bit alone. If it comes with a minor performance hit, OK, i can live with that, I agree with Lukas in that aspect, you don't spend lots of time checking/casting anyway. As for hinting/casting would not be 'php-ish', i don't see it that way, i look at php as a language of possibilities, not restrictions. As I said, i'm a framework developer and it would greatly improve readability, usability and quality when you can use type hinting/casting. Consider a pretty common architecture where you have a service layer which does validation and stuff and then passes control to 'deeper' parts in the framework. Your service layer could have a casting hint, while the more inner components could have a strict hint. There you can trust the data is of the type you wanted, otherwise there is something wrong anyway. The most important thing is that it is _optional_, you have the _choice_ to use it. Regarding syntax, to me it is totally intuitive that foo((int) $bar) tries to do a cast and foo(int $bar) is strict, it's also easy to explain to students, put parenthesis around your type name and it's a cast, whether it is in an assignment or a method declaration it doesn't matter. Seeing the discussion I think there is consensus it shouldn't be in 5.3. I think it shouldn't be in 5.x total, the 5.x branch is already _loaded_ with lots of new cool stuff and in my opinion all focus should be on getting a 6.0 release asap. I know, i'm 'just' a php user but maybe I can inspire someone in taking the 'right' course. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
