Hello George,
Sunday, July 20, 2003, 5:30:43 PM, you wrote:
>> - Completely force a derived class now to implement the same amount of
>> parameters with the same typehints as the inherited one. When it comes
>> to typehints theory allows to provide same or parent types but that would
>> be much harder to implement so only allowing the same type is just easier.
>>
>> We also don't have a way to specify typehints and param amount for functions
>> declared at c-level. Further more we are not able to specify access type of
>> a method declared at c-level (static/public/protected/private/final).
GS> Are you talking about just interface implementation here, or general
GS> inheritance. If the latter, I'm not a big fan of this.
To be type correct we would need it also in general inheritance. But for the
moment i think it is somewhat important to give interfaces a sense at all. So
i can live with interfaces only pretty well.
>>
>> - Complete work on exceptions and find a solution on when to throw exceptions
>> and when to use errors.
>>
>> I still do not see any BC problems with making try/catch blocks to convert
>> E_WARING, E_NOTICE & E_ERROR to exceptions (assumed the problemntaic E_ERRORS
>> are changed to E_CORE or such). Why no BC? Simply becuase using try/catch
>> with old libs and relying on error capturing is an antilogy in itself.
>> Especially when thinking about the very limited capabilities in handling
>> errors the old way.
GS> As you know, I'm a big fan of this in th case of E_ERROR, because there
GS> really are no BC issues involved. The E_WARNING and E_NOTICE errors
GS> are different though, and seem like a serious concern to me. This has
GS> been gone over a number of times, but the example that worries me is
GS> try {
GS> new_func();
GS> }
GS> catch (Exception $e) {}
GS> function new_func() {
GS> /* .... do some stuff ...*/
GS> old_func();
GS> /* ... more stuff ... */
GS> }
GS> old_func() has been coded to throw warnings for non critical issues (as
GS> informational messages). Broken.
GS> E_NOTICE is even worse, since many folks code does not run clean under
GS> E_NOTICE. Now you include a file in your try block somewhere and you
GS> get an exception.
GS> Seems icky.
As i said combining both thechniques makes no sense and converting the error
mechanisms of old code when preparing new things shouldn't be a problem at all
since you have to change several things already without the exception issue.
>> Discuss about adding 'thorws' to a method declaration and a flag for c-level
>> functions so that the compiler can emit an error when such a method is used
>> without try/catch.
GS> Huh? Shouldn't it be my choice to put a try/catch block around a
GS> function? Why should I be forced to catch ay errors it emits?
For the moment it's only an idea. And i don't know if it is a good one :-)
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
