On Mon, Jun 28, 2010 at 20:17, Stas Malyshev <smalys...@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


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

Etienne Kneuss

Reply via email to