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?
-Sterling
--
"I can't give you a brain, so I'll give you a diploma"
- The Great Oz, The Wizard of Oz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
