Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46095
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.186 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=KsiYP9GhG5A7thbZG7h9tooOZwaj3J3eYeXTC4PxkTaPSyr2xlA2G4r/5dEDrmuKk4
         gEZ4Mk9eaWVVOfTd3pnS0xftljQ0ExiW5+UR3cMEYDx9nmFj67yC+viDsgbTIaQ5Q6SS
         I5yAeol70eKeGwCpXs0saVZBeMOyHABsraN4M=
MIME-Version: 1.0
In-Reply-To: <4B045234.1010804@zend.com>
References: <b9339a730911180023h32eec476y940abc907012b5b6@mail.gmail.com>
	 <4B045234.1010804@zend.com>
Date: Thu, 19 Nov 2009 11:15:58 +0800
Message-ID: <b9339a730911181915h1f371e84kb430041e9ced0742@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=000e0cd4ce923a80aa0478b0c7d6
Subject: Re: [PHP-DEV] The inconsistencies/flaws of PHP5's object model
From: diogin@gmail.com (Jingcheng Zhang)

--000e0cd4ce923a80aa0478b0c7d6
Content-Type: text/plain; charset=ISO-8859-1

Hello Stanislav,

2009/11/19 Stanislav Malyshev <stas@zend.com>

> Hi!
>
> Yes, this is the expected result. PHP is not Javascript, sorry :) Methods
> and properties are different things in PHP, so the syntax assumes you refer
> to method when you call $o->f(). You could use other syntaxes if you need to
> use a property as callable (see call_user_function, etc.).
>
>
Before PHP 5.3, $className::$methodName() is not allowed, people who needs
this call should use call_user_func(array($className, $methodName)) instead,
which is ugly and verbose. Since PHP 5.3 adds closure support, I think the
syntax "$o->f()" should also check whether "f" is a closure, if it is, then
call it.


>
>
 1. There is no way to add/remove instance-level members (both properties
>> and
>> methods) to class dynamically, but a way to add them to instance itself,
>> which is a little buggy as above codes turns out;
>>
>
> It is not "buggy", it is how the language is - class is a fixed template,
> object is a mutable instance of this template.
>
>
As PHP is a dynamic language, it might be acceptable to dynamically change
the "fixed template" nature of class, especially when programming PHP in
prototype-based way by using class as "object" (which I think is much
natural to class-based programming in PHP since "class" is a static concept,
while "object" is a dynamic concept which suits PHP interpreter's running
model perfectly).


>
>  3. There are __get(), __set(), __call() for instance-level members, and
>> __callStatic() for static methods, but lacks __getStatic() and
>> __setStatic()
>> for static properties;
>>
>
> That may be added if somebody provides a good patch.
>

I found this path provided by Lars Strojny in wiki page (
http://wiki.php.net/rfc/static-classes):
http://lars.schokokeks.org/php/static-classes-002.diff

I'm not sure wether this patch is good.


>
>  4. While using static class as object (general concept of "object", not
>> "instance" here), it's extremely complex to simulate "prototype object",
>> as
>>
>> static members simply do not duplicate themselves at all while inheriting,
>> therefore all of the child classes share a single static member of the
>> parent class;
>>
>
> That's how static members work - they belong to the defining class.
>
>
>  6. Static methods are allowed in interfaces, but not allowed in abstract
>> class, which breaks the rule of abstraction;
>>
>
> You can have static functions in abstract classes. What you can not have is
> abstract static functions, because it makes little sense - static function
> belongs to the class, so if it's abstract - meaning needs to be redefined -
> then what exactly you are defining? You'll define static functions in child
> classes anyway and you'll be calling them explicitly by class name (i.e.
> ChildClass::foo, not BaseClass::foo).
>
>
Yes I mean abstract static function here, sorry for my typo. Abstract static
function is meaningful: You can force child class to implement it, and
combining it with "Late Static Binding" one can implement "Template Method
Pattern" in prototype-based way here:

<?php
abstract class a {
    final public static function f() {
        static::g();
    }
    abstract public static function g();
}
final class c extends a {
    public static function g() {
        echo 'c';
    }
}
final class d extends a {
    public static function g() {
        echo 'd';
    }
}

$className = 'c';
$className::f();
$className = 'd';
$className::f();
?>

This is equivalent to "Template Method Pattern" in instance-level way. In
addition, interfaces and abstract classes are both abstraction of a specific
API, methods declared in interfaces should be totally identical to methods
declared in abstract classes, aren't they? One can implements an interface
with an abstract class, and get an abstract static function in abstract
class:

<?php
interface i {
    static function f();
}
abstract class c implements i {

}
var_dump(get_class_methods('c'));
$method = new ReflectionMethod('c', 'f');
var_dump($method->isAbstract());
?>

It is meaningless to forbid abstract static function.


>
>  7. An interface which has only static methods cannot ensure static methods
>> in a class which implements it.
>>
>
> I'm not sure what you mean here, could you provide a short code example
> that you think should be working and doesn't?
>
>
For example:

<?php
interface i {
    static function f();
}
class c implements i {
    public static function f() {
        echo 'c';
    }
}
function g(i $i) {
    var_dump($i);
}
g('c');
?>

This result is more or less expected since type hinting only works on
variable types, and the argument 'c' is a string, but as a type, the
interface i cannot hint the fact that class c "is a type of i".

Thanks for your patient reply!


>
> --
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com
>



-- 
Best regards,
Jingcheng Zhang
P.R.China

--000e0cd4ce923a80aa0478b0c7d6--