[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-cvs
Subject:    Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
From:       Etienne Kneuss <webmaster () colder ! ch>
Date:       2010-06-28 18:38:48
Message-ID: AANLkTikKxkqNeycPSF7mC8BJP_mKvwt5CqZAXEaEu8Xm () mail ! gmail ! com
[Download RAW message or body]


Hi,

On Mon, Jun 28, 2010 at 20:17, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>
>  1) arguments can be gathered dynamically in the function, using
>> func_get_args. For that reason, PHP gracefully allow a call with too many
>> arguments.
>>
>
> Isn't it the case today?
>

It's the case at the time of the calls. But not when overriding a method:
class A { public function foo($a) { } }
class B extends A { public function foo() {} }
is considered invalid, but $obj->foo($arg); would be perfectly valid for
both objects.


> Maybe also we can add some syntax like:
> function foo($a, $b, ...) - where ... means "I'll deal with those arguments
> myself, ignore any compatibility checks" so if the prototype is
> foo($a,$b,$c) $a and $b would be checked but not $c and the function is
> considered to have enough args.
>

I'd find that syntax pretty explicit and easy to understand, it wouldn't
break any BC.


>
>  2) a child method should be allowed to define type hints in a
>> contra-variant
>> manner (currently, it's invariant)
>>
>
> This needs to be fixed.
>
>  3) a child method should be allowed to return a ref even if the parent
>> method is not defined to do so. (returning a ref is an additional
>> constraint, and following co-variance of return values, it should be
>> allowed). The basic example of this annoyance is: abstract class A
>> implements ArrayAcces { public function&__offsetGet($name) { ... } }
>>
>
> This needs to be fixed too.
>
>  4) all in all: it shouldn't throw a fatal error, those are not critical
>> situations for the engine.
>>
>
> I'd say in general OO part of PHP seems to be much more strict and
> Java-like than the rest. I'm not sure it's good. I'd demote all situations
> where the engine has a way to proceed to at least warning level.
>

I don't believe that any of those checks causes difficulty for the engine,
especially considering that internal classes can pretty much to what they
want anyway.


>
>  I'd like to propose to relax such checks, by either allowing more (e.g. 1,
>> 2
>> and 3) which can be painful and complicated, or simply removing those
>> checks.
>>
>
> I think we shouldn't remove them - we should fix them. It doesn't seem to
> be too hard, IMHO.
>

Enforcing contra-variance can become a tad bit tricky when it comes to:
1) argument vs no argument
2) argument with/without null as default value
3) by ref or not (with/without default values)

We should probably specify it formally in which case a prototype is
accepted, and then see what needs to be fixed.

Also, checking for subtyping in PHP is O(n) which is "slow", but I don't
believe it's a concern big enough to change the way we implement
"instanceof".

Best,

-- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>



-- 
Etienne Kneuss
http://www.colder.ch


[prev in list] [next in list] [prev in thread] [next in thread]