On Fri, 2003-03-28 at 10:52, Andi Gutmans wrote:
> At 03:56 PM 3/28/2003 +0100, Sebastian Bergmann wrote:
> >Andi Gutmans wrote:
> > > OK so maybe we should go ahead and nuke it and save us the argument.
> >
> > Please, no.
>
> The main problem is that people are getting carried away and instead of
> looking at the big step forward the OOP model has done since PHP 4 and how
> useful it will be, they are thinking of how much is left to change PHP into
> Java. i.e. it is going to be a never-ending story until PHP successfully
> compiles Java code (from now on I'll use the term deltaJava as the delta
> between Java and PHP).
> Therefore, I prefer nuking what I consider a cute nice-to-have feature
> which I don't consider critical, instead of making the extra step and
> waiting for the next complaint found about a feature which exists in deltaJava.
>
I personally agree. I think that type-hints are nice, but will ultimately be too much a pita if the error can not be recovered from.
One thing, just a wild, and half-baked idea, but why not have a E_MAKE_US_ALL_HAPPY, error level, that doesn't call the current function (because types are wrong, but doesn't halt script execution either.
My concern with typehints is two-fold:
1) It forces pointless type-conformity in the majority of PHP code. It does have some good uses (SOAP for example), but I fear it will be overused by OO-zealots, who still haven't gotten that PHP isn't Java - and that's a *GOOD* thing.
2) It throws an E_ERROR. If this is going to be a runtime feature, I want to have someway to recover from it. Perhaps it can limit the function from being called, but not kill script execution?
Changing PHP's behavior with a different error level is only a tad bit better than adding an INI directive. In general I'd like the core language to behave the same no matter what error level or INI settings.
I say nuke type-hints and let the purists use instanceof.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
