Hi, 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 "instanceof". Best, -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > -- Etienne Kneuss http://www.colder.ch