IMHO,
This is acually the first ive heard of aggergate. I don't like it at all. I
never liked overload ither. If you are defining a class libary you need some
procedural code just to define the class libary. even for things like
auto-documentors like php-doc. They no nothing about the aggerated class or
overloaded class. I think that these options should be apart of the language
like the origional email said. like multiple inheritance (aggerate) and maybe a
class blah overloaded
{
}
for the overload
i really really don't like ither one of these functions. I like the
functionality of them but i think the origional conserns are way to valid to
say that the people who are going to be using these will know enough to take
all of that into consideration. Changing the engine so it could accecpt
multiple inheritance wouldn't even be hard or accecpting the overloaded class
option. I really feel strongly about having procedural code that defines the
class higher archy is really really bad!
#brad
--- Yasuo Ohgaki <[EMAIL PROTECTED]> 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
>
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
