On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig <kris.cr...@gmail.com> wrote: > On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara <ircmax...@gmail.com>wrote: > >> Stan, >> >> On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass <sv_for...@fmethod.com> wrote: >> >> > Hi! >> >> >> >> I agree with you. The one case where this syntax may be very useful is >> if >> >>> we want to implement class casting. So introduce a pair of magic >> methods >> >>> >> >> >> >> I do not think we want to implement class casting. I'm not sure how >> >> class casting even makes sense - if the object is of one class, how can >> >> you just make it into another class by casting? If you mean "casting" >> >> actually returns another object of different class, then just make a >> >> method for that that returns that object, I do not see how obscuring the >> >> purpose of this operation with unobvious syntax would help. >> >> >> > >> > The discussion is starting to drift very far from my original proposal. >> > >> > Instead of trying to guess what I mean, can't people just refer to my >> very >> > simple definitive proposed behavior? >> > >> >> My point was that what I posted was the only way that I can see for the >> original proposal to be useful. >> >> Anthony >> > > Though I'm clearly in the minority on this, I for one think this proposal > does have more merit than is being argued. There seems to be general > agreement all around that this would provide a benefit as it pertains to > code readability-- Not just by humans, but theoretically by doc/etc parsers > as well. > > This is where we get into arbitrary, subjective territory. To me, that > benefit in and of itself is sufficient to warrant this feature. To many of > you, it is not enough. > > The tie-breaker for me is the fact that, though the benefits are modest, > there's really no noticeable cost, either. The argument seems to, > essentially, break down as follows: "This feature isn't worth our time." > .... "Yes, it is!" .... "No, it isn't."
Every feature has a cost, even if that cost is just maintaining the code. Doing language changes for minority use cases, which already have sensible solutions, doesn't make much sense. Another aspect here is that there is no reasonable syntax for this feature, at least I can't think of one: * The syntax `$foo = (InterfaceName) $container->service` is completely out of question. It looks like a cast, but wouldn't actually do a cast. * Same is to be said about `InterfaceName $foo = $container->service`. This syntax implies that the $foo variable will always be of type InterfaceName, even if it is later reassigned. It's not a sensible syntax for a one time validation * The other three syntaxes that were mentioned were just as unclear. E.g. `$foo = $container->service as InterfaceName` again looks like a strange cast syntax and `$foo = $container->service is InterfaceName` looks like the assignment should evaluate to a boolean (i.e. `is` is some kind of `instanceof`). On the other hand, the current ways of accomplishing the same goal are well-established and easy to understand: * Using a docblock: /** @var $foo IntefaceName **/ * Using an assertion: assert($foo instanceof InterfaceName). I think that the assertion is a rather concise and clear way to do this. It is much more obvious than some new and obscure `$foo = (InterfaceName $container->service)` syntax. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
