Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40456
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain noodles.gr from 74.125.46.28 cause and error)
Message-ID: <641f88250809110035w57abd979v657b6f187980c333@mail.gmail.com>
Date: Thu, 11 Sep 2008 10:35:16 +0300
Sender: antoniadis@noodles.gr
To: "Edward Z. Yang" <edwardzyang@thewritingpot.com>
Cc: internals@lists.php.net
In-Reply-To: <gaa5i5$93v$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_58099_9510590.1221118516102"
References: <005601c912e5$46a29280$d3e7b780$@com> <gaa5i5$93v$1@ger.gmane.org>
Subject: Re: [PHP-DEV] PHP mixin RFC
From: george@noodles.gr ("George Antoniadis")

------=_Part_58099_9510590.1221118516102
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Personally I think that traits is a lot safer than mixing classes.There will
be a lot of things that will need to be considered in order to make it
logical for developers to use.

Quote from the RFC:
"Any method or property that already exists in the class or parent/extended
class cannot be changed unless using class_mixin() see below."

I'm pretty sure this is against all beliefs in the php world.
Runtime merging of classes and overriding methods is a no-no for me.

Traits seems much more safe since you cannot initialize a trait and can only
used to "flatter" other classes.
The proposed way of mixins will create confusion when trying to continue
development on an ongoing project and will need A LOT of extra documentation
just for explaining the hierarchy of the mixed classes.

A very simple case of mixins for php (that allready is implemented) can be
seen in Advogato: Mixins for php.
It has the following example.

*******************************************
class Person {
    var $job = "person";
    function show_job() {
        echo "Hi, I work as a {$this->job}.";
    }
}

class Bartender {
  var $job = "bartender";
    function show_job() {
        echo "BARTENDER: ";
        Person::show_job();
    }
}
$b = new Bartender;
$b->show_job();
**************************************************

If you look at the example you can see that the Bartender class does NOT
extend the Person class, but when using Person::show_job(); the person's
method have access to the $b object's variables as if the bartender class
extended the person class.

IMO this is the safest way we can use mixins without getting into the
troubles of creating too many (complicated) ways to do the same thing.

G.


On Thu, Sep 11, 2008 at 7:07 AM, Edward Z. Yang <
edwardzyang@thewritingpot.com> wrote:

> Jonathan Bond-Caron wrote:
> > http://wiki.php.net/rfc/mixin
>
> It seems to me that class_mixin() is a bad idea for the core; it's more
> of a runkit type functionality than traits. After all, we don't allow
> dynamic inheritance, or dynamic interfaces...
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

------=_Part_58099_9510590.1221118516102--