I agree with Yasuo - these functions put a de-facto functionality standard
in a highly debated topic that has not yet reached consensus - the least we
could do is point out to people that it may very well change in the future...
Zeev
At 04:40 AM 4/5/2002, Yasuo Ohgaki wrote:
>--disable-experimental-aggregate and
>--disable-experimental-overload?
>
>Just in case we really want to make it optional and have new way
>for overloading/multiple inheritance.
>We can document these features as EXPETIMENTAL as long as we want,
>right?
>
>--
>Yasuo Ohgaki
>
>
>Kristian Koehntopp wrote:
>>I have several observations regarding the newly implemented
>>aggregate() und overload() extensions. Depending on the
>>correctness of these observations you may want to reconsider the
>>inclusion of these extensions in the current build of PHP.
>>The following has not in its entirety verified in the source and
>>may be incorrect or incomplete. Please correct me.
>>Situation:
>>$obj = new Origclass; aggregate($obj, "Classname"); is a
>>function which adds all instance variables and methods from
>>class Classname to an object $obj of an original class
>>Origclass. There are variations of aggregate which allow you to
>>add instance variables and methods selectively by enumeration
>>and regex.
>>Observation:
>>aggreate and friends break the introspection in PHP, and may
>>interfere with serialization and sessions. This is, because
>>get_class($obj) returns Origclass, and no trace of Classname.
>>Also, $obj is_a() Origclass, but not is_a(Classname), leading to
>>serialization of $obj as a pure Origclass, and reinstantiation
>>as a pure Origclass with no methods from Classname at all.
>>This is the situation of serialize() in PHP 3 at a slightly
>>elevated level. Reminder: In PHP 3, serialize() did not record
>>the class of an object on serialization, and unserialize()
>>consequently produced an object with no methods at all, which is
>>in fact quite useless.
>>Also, because of the fine grained nature of the more advanced
>>variations of aggregate, there is no fast way to describe the
>>class or type of an object instance. The only way to completely
>>describe an object is to completely enumerate its instance
>>variables and instance methods. Essentially, get_class and
>>friends become meaningless.
>>Alternative:
>>aggregate is a badly designed way to introduce multiple
>>inheritance like functionality. There are at least two tested
>>ways to implement MI functionality. Statically typed languages
>>such as C++ set type == class and implement pure MI. Regarding
>>PHP, this would lead to
>>class C extends A, B { ... }
>>with the order of A and B being important. Also,
>>get_parent_class() would need to be modified to return
>>inheritance level information or inheritance graph information
>>together with class names in order to produce meaningful
>>information. Something like
>> $v = get_parent_class($complicated_object);
>>$v would be
>> array("A" => "B", "B" => "C", "B" => "D");
>>for
>> class A extends B ...
>> class B extends C, D ...
>>An alternative, possibly cleaner way would be the introduction
>>of interfaces and categories. In this scenario we keep single
>>inheritance. We introduce declarations of interfaces, which may
>>contain a number of instance variables and functions. Interfaces
>>are a simple declaration of these, there is no implementation at
>>all in an interface.
>>A class may claim conformity with an interface. This means that
>>the class at least has all the instance variables the interface
>>demands and has at least implementations for all member
>>functions of the interface. The class may implement all this
>>independently or it may import a category.
>>A category is class-subset, and always an implementation of an
>>interface (you cannot define a category for which no interface
>>definition is being known).
>>Interfaces and Categories are found in some dynamically typed
>>languages, sometimes under slightly different names. They
>>separate type and class, and in order for them to function in
>>PHP we would need enumerative functions and predicates to
>>complement the new language constructs (get_defined_interfaces(),
>>get_defined_categories(), conforms_to($interface_name)).
>>Recommendation:
>>As-is aggregate() is a broken design, and will break existing
>>older functionality. It will create a number of support issues,
>>and later backward compatibility issues. It may inspire even
>>more broken "fixes" for these issues, effectively uglifying the
>>language itself or at least its object system.
>>The best would be to remove aggregate() completely, and bury it.
>>It should be replaced by a proper MI system, probably one for a
>>dynamically typed language, as PHP is such a language.
>>If aggregate() functionality is being used right now, and is
>>critical, it should be kept, properly documented, the drawbacks
>>spelled out in all its ugliness and its use strongly
>>discouraged. It should be clearly marked as obsolete from day 1,
>>and may be removed at any time. If someone uses this feature
>>despite the warning labels, this person deserves everything that
>>happens.
>>
>>Situation:
>>The overload() extension allows userland code to intercept get,
>>set and call operations on the instance variables and instance
>>functions of an object. It does this by defining the special
>>fixed name functions __get, __set and __call in a class, which
>>are enabled by calling overload() on this class.
>>It also allows, according to Sebastian Bergmann, and in spite of
>>the current documentation at
>>http://www.php.net/ref.overload.php, __get_x(), __set_y() and
>>__call_x() functions in order to intercept accesses and calls to
>>instance variable x and method y respectively.
>>I haven't verified this in source, but Sebastian claims it
>>works.
>>Observation:
>>If this is NOT the case, I have no issue with overload(). It is
>>dangoerous, but it is an expert feature and the design is okay.
>>If overload() allows for __get_x(), though, this is bad design.
>>The reason for this is that we get namespace pollution and,
>>again (*), automatically called callback functions with a
>>variable name. There will interoperate badly with inheritance,
>>with dynamically created, undeclared instance variables and with
>>aggregate().
>>Recommendation:
>>If overload() indeed supports variably named callback functions
>>such as __get_x(), support for this should be removed in order
>>to avoid a number of possible inconsistencies and namespace
>>pollution.
>>
>>End Rant, fire away...
>> Kristian
>>(*) We had them with PHP 3 constructor names, which were an
>> extremely bad idea in the first place.
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
