Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Personally, I don't get deep into how PHP works inside, I'm just a
PHP-programmer (the man from userland). For me it will surely be
better to use 'insteadof', not 'instead'. And It seems to me more
natural to use the following syntax when using grafts:
class Foo {
use MyGraft {
public graftedClassMethodBar() as bar();
}
}
$foo = new Foo();
$foo-bar();
2009/10/15 Tom Boutell t...@punkave.com:
I'm very concerned about the practical consequences of introducing
traits without state.
Lacking support for properties (state) in traits, programmers will
immediately start hacking properties in anyway.
I see two approaches:
A. They could do this using static hashes in global variables or a
separate class. The result is a garbage collection failure as these
references to $this will never go away. Designed-in GC failures are
unacceptable post PHP 5.3.
B. PHP allows you to define properties at runtime. That is, you can write:
$this-title = 'my title';
Without declaring var $title; at the class level.
But PHP 6 seems to be moving toward more strictness, not less, and
this style encourages the use of undeclared variables with the
resulting potential for missed bugs.
* * *
Also, the 'instead' keyword is baffling - it could mean replace A with
B or replace B with A depending on how you place your mental comma - I
much prefer the assignment syntax alternative, or 'insteadof' which is
unambiguous.
On Wed, Oct 14, 2009 at 4:07 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 14.10.2009, at 22:03, Stanislav Malyshev wrote:
Hi!
So lets warm this up again.
HEAD is for development .. so lets get this into HEAD so that it will be
part of the next bigger PHP release for sure!
Well, the code is sitting here
http://github.com/gron/php-src/tree/PHP_6-traits
and waits to be merged. :)
I thought before merging code it would be useful to have some discussion
on if the code is actually doing what we want. If it's based on
http://wiki.php.net/rfc/horizontalreuse then for example I can see some
potential issues for bytecode caching related to renaming and changing
visibility.
Also, it is not clear that we want grafts there at all, some aspects of
them seem to get too hairy, esp. $this issue or statics.
i think Stefan is fully aware of that probably there will be a discussion
first ..
but i think we all agree that this feature is very high on the list of what
people want and therefore i wanted to get this discussion going, so that
after its concluded traits can be commited to HEAD.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Regards,
Victor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On Wed Oct 14 04:07 PM, Lukas Kahwe Smith wrote:
On 14.10.2009, at 22:03, Stanislav Malyshev wrote:
Hi!
So lets warm this up again.
HEAD is for development .. so lets get this into HEAD so that it
will be part of the next bigger PHP release for sure!
Well, the code is sitting here
http://github.com/gron/php-src/tree/PHP_6-traits
and waits to be merged. :)
I thought before merging code it would be useful to have some
discussion on if the code is actually doing what we want. If it's
based on http://wiki.php.net/rfc/horizontalreuse then for example I
can see some potential issues for bytecode caching related to
renaming
and changing visibility.
Also, it is not clear that we want grafts there at all, some aspects
of them seem to get too hairy, esp. $this issue or statics.
i think Stefan is fully aware of that probably there will be a
discussion first ..
but i think we all agree that this feature is very high on the list of
what people want and therefore i wanted to get this discussion going,
so that after its concluded traits can be commited to HEAD.
Has it been discussed to add a portion of the patch to HEAD?
Reading up on scala, I really like what they've done with traits (as a
developer):
http://www.scala-lang.org/node/117
I've updated the RFC with an example:
http://wiki.php.net/rfc/traits#scala_synthax_and_practical_example
Hopefully, people can agree on a simple patch that ignores conflict
resolution / aliasing solution and just adds:
trait User_Comments {}
class App_Document with User_Comments {}
// Or the original syntax
class App_Email {
use User_Comments;
}
The details of conflict resolution, if the use cases are strong enough can
come later.
Grafts well... the re-use is interesting but I worry about how php is going
to evolve is you start offering that much flexibility.
Just my thoughts, great work though.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Sure, the discussion will be necessary to fix the final design of the remaining rough edges like choice of keywords. The current state of the code is basically documented by the test case. They cover all syntactical features and their implications for using traits. However, this functionality is covered by the Traits part of the RFC as well. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. Personally, I see question of Traits or Grafts as an exclusive one. It would not do any good to have both of them. And, grafts have not been implemented. Best regards Stefan -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Hi: On 14 Oct 2009, at 22:44, Tom Boutell wrote: I'm very concerned about the practical consequences of introducing traits without state. Well, we have not found a sufficient design until now, which would fit nicely into PHP from dynamic and simplicity perspective. A. They could do this using static hashes in global variables or a separate class. The result is a garbage collection failure as these references to $this will never go away. Designed-in GC failures are unacceptable post PHP 5.3. Doing this would be less than advisable. B. PHP allows you to define properties at runtime. That is, you can write: $this-title = 'my title'; Without declaring var $title; at the class level. But PHP 6 seems to be moving toward more strictness, not less, and this style encourages the use of undeclared variables with the resulting potential for missed bugs. Thats the currently preferred approach from my perspective. The only thing you are going to lose here is a notion of separation of state from different traits, compared to a language supported approach. However, if you prefer to be more strict, it is still perfectly possible to circumvent this problem by using getters and setters. Also, the 'instead' keyword is baffling - it could mean replace A with B or replace B with A depending on how you place your mental comma - I much prefer the assignment syntax alternative, or 'insteadof' which is unambiguous. Yes, that was discussed before, but unfortunately did not make it into the list of alternative syntaxes, will try to keep track of it. Best regards Stefan On Wed, Oct 14, 2009 at 4:07 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 14.10.2009, at 22:03, Stanislav Malyshev wrote: Hi! So lets warm this up again. HEAD is for development .. so lets get this into HEAD so that it will be part of the next bigger PHP release for sure! Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits and waits to be merged. :) I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. i think Stefan is fully aware of that probably there will be a discussion first .. but i think we all agree that this feature is very high on the list of what people want and therefore i wanted to get this discussion going, so that after its concluded traits can be commited to HEAD. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On Thu, Oct 15, 2009 at 10:42 AM, Stefan Marr p...@stefan-marr.de wrote: Hi: On 14 Oct 2009, at 22:44, Tom Boutell wrote: I'm very concerned about the practical consequences of introducing traits without state. Well, we have not found a sufficient design until now, which would fit nicely into PHP from dynamic and simplicity perspective. Could you elaborate a little? I'm having trouble understanding why we can't just implement trait properties according to exactly the same policy we're using for methods with regard to conflict resolution/renaming and all the rest of it. B. PHP allows you to define properties at runtime. That is, you can write: $this-title = 'my title'; Without declaring var $title; at the class level. Thats the currently preferred approach from my perspective. The only thing you are going to lose here is a notion of separation of state from different traits, compared to a language supported approach. However, if you prefer to be more strict, it is still perfectly possible to circumvent this problem by using getters and setters. So the trait would continue to use this tactic (runtime assignment to previously undeclared properties) internally, and wrap that in getters and setters... Will PHP ever include optional warnings for the use of undeclared properties? If so, then it doesn't make sense to also institutionalize their use as the only right way to have state in traits. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Hi:
Has it been discussed to add a portion of the patch to HEAD?
Hopefully, people can agree on a simple patch that ignores conflict
resolution / aliasing solution and just adds:
Ehm, hopefully not...?
The power of traits is the explicit resolution of conflicts.
And at least for me, that is the interesting part here.
I agree that mixins (traits without explicit conflict resolution) are
easier to begin with, but they have problem in the long run.
Linearization introduces brittle architectures, which does not cope
well with changes.
Tom mentioned that he thinks that PHP6 is moving in a more strict
direction, probably that is also motivated by the large systems
already out there, for which people tend to prefer more strict
language features.
In this sense, an explicit conflict resolution is a must-have.
Anyway, could I ask you to move your changes from the outdated RFC
over to the one we are talking about? (http://wiki.php.net/rfc/horizontalreuse
)
Best
Stefan
PS: Is there a way to have a watermark or something which marks the
old RFC as outdated? I don't want to delete it for documentation
purpose...
trait User_Comments {}
class App_Document with User_Comments {}
// Or the original syntax
class App_Email {
use User_Comments;
}
The details of conflict resolution, if the use cases are strong
enough can
come later.
Grafts well... the re-use is interesting but I worry about how php
is going
to evolve is you start offering that much flexibility.
Just my thoughts, great work though.
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Aloha,
So lets warm this up again.
HEAD is for development .. so lets get this into HEAD so that it will
be part of the next bigger PHP release for sure!
regards,
Lukas
On 13.10.2008, at 21:12, Stefan Marr wrote:
Hello,
the last time the topic traits has been discussed is already a while
ago.
At this time, there have been two very different opinions out there,
about
how exactly this horizontal reuse should actually look like and no
common
consensus was found. In the following RFC, I describe both
approaches in
more detail.
For neither of them is a work patch available, but this should not
hinder
discussion. In this step, we should find an agreement on the
direction, in
which PHP has to evolve.
The part about Traits in this proposal, is equal to the former RFC.
The
second
Part introduces the new variation and is an alternative approach to
traits.
Looking forward for your opinions,
Kind Regards
Stefan
Request for Comments: Horizontal Reuse for PHP
~~
:Version: 2.0alpha
:HTML: http://www.stefan-marr.de/artikel/rfc-horizontal-reuse-for-php.html
:TXT: http://www.stefan-marr.de/rfc-horizontal-reuse-for-php.txt
:Author: Stefan Marr php.at.stefan-marr.de
:Previous RFC: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
:Related RFC: http://wiki.php.net/rfc/nonbreakabletraits
.. contents::
This RFC will discuss two different approaches to reuse behavior
independently
from the class hierarchy i.e. in an horizontal manner. The main
motivation
of both approaches is to provide a broader opportunity to model
classes and
class hierarchies with a clear conceptual background and optimal
code reuse
at
the same time. Furthermore, the main distinction to other approaches
is the
explicit handling of conflicts resulting from overlapping interfaces
in
complex
reuse scenarios. Both approaches would be valuable extensions to the
PHP
language, but both of them have their own benefits and drawbacks.
Thus, this RFC is meant to provide a base for further discussion to
be able
to decide, which variant is the most PHP-like reuse mechanism.
Why Do We Need Horizontal Reuse?
Code reuse is one of the main goals that object-oriented languages
try to
achieve with inheritance. Unfortunately, single inheritance often
forces
the developer to take a decision in favor for either code reuse *or*
conceptual clean class hierarchies. To achieve code reuse, methods
have
either to be duplicated or to be moved near the root of the class
hierarchy,
but this hampers understandability and maintainability of code.
To circumvent this problems multiple inheritance and Mixins have been
invented.
But both of them are complex and hard to understand. PHP5 has been
explicitly
designed with the clean and successful model of Java in mind:
single inheritance, but multiple interfaces. This decision has been
taken
to avoid the known problems of for example C++. The presented
approaches
have
been designed to avoid those problems and to enable designers to build
conceptually clean class hierarchies without the need to consider
code reuse
or complexity problems, but focusing on the real problem domain and
maintainability instead.
Limitations to Reuse in Single Inheritance Languages
There are several issues with reuse in PHP. To achieve as much reuse
as
possible you will probably move methods as high as possible in your
inheritance
hierarchy. At this point, there is a trade-off between conceptual
consistency
and reuse, because classes starts to have methods they do not need.
So, when
it
is decided that the conceptual consistency is more valuable because of
understandability of the class model, code duplication is caused or
needs to
be
worked around by e.g. delegation, which is not always as nice as
method
implemented in the class tree.
Beside conceptual issues, there are problems with third-party code
you can
not
or might not want to modify. The following code illustrates the
current
implementation of an extended version of the PHP reflection API which
provides
detailed access to doc comment blocks. ``ReflectionMethod`` and
``ReflectionFunction`` are classes from the reflection API and have
to be
extended with exactly the same code. In this case it is impossible
to change
the classes itself, because they are not under our control i.e. they
are
implemented in C as part of the language.
::
?php
class ezcReflectionMethod extends ReflectionMethod {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
?
Thus, eventually, we end up with much duplicated code in both classes
extending
the original extension classes.
Which
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On 14 Oct 2009, at 21:26, Lukas Kahwe Smith wrote:
So lets warm this up again.
HEAD is for development .. so lets get this into HEAD so that it
will be part of the next bigger PHP release for sure!
Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits
and waits to be merged. :)
Best regards
Stefan
regards,
Lukas
On 13.10.2008, at 21:12, Stefan Marr wrote:
Hello,
the last time the topic traits has been discussed is already a
while ago.
At this time, there have been two very different opinions out
there, about
how exactly this horizontal reuse should actually look like and no
common
consensus was found. In the following RFC, I describe both
approaches in
more detail.
For neither of them is a work patch available, but this should not
hinder
discussion. In this step, we should find an agreement on the
direction, in
which PHP has to evolve.
The part about Traits in this proposal, is equal to the former RFC.
The
second
Part introduces the new variation and is an alternative approach to
traits.
Looking forward for your opinions,
Kind Regards
Stefan
Request for Comments: Horizontal Reuse for PHP
~~
:Version: 2.0alpha
:HTML: http://www.stefan-marr.de/artikel/rfc-horizontal-reuse-for-php.html
:TXT: http://www.stefan-marr.de/rfc-horizontal-reuse-for-php.txt
:Author: Stefan Marr php.at.stefan-marr.de
:Previous RFC: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
:Related RFC: http://wiki.php.net/rfc/nonbreakabletraits
.. contents::
This RFC will discuss two different approaches to reuse behavior
independently
from the class hierarchy i.e. in an horizontal manner. The main
motivation
of both approaches is to provide a broader opportunity to model
classes and
class hierarchies with a clear conceptual background and optimal
code reuse
at
the same time. Furthermore, the main distinction to other
approaches is the
explicit handling of conflicts resulting from overlapping
interfaces in
complex
reuse scenarios. Both approaches would be valuable extensions to
the PHP
language, but both of them have their own benefits and drawbacks.
Thus, this RFC is meant to provide a base for further discussion to
be able
to decide, which variant is the most PHP-like reuse mechanism.
Why Do We Need Horizontal Reuse?
Code reuse is one of the main goals that object-oriented languages
try to
achieve with inheritance. Unfortunately, single inheritance often
forces
the developer to take a decision in favor for either code reuse *or*
conceptual clean class hierarchies. To achieve code reuse, methods
have
either to be duplicated or to be moved near the root of the class
hierarchy,
but this hampers understandability and maintainability of code.
To circumvent this problems multiple inheritance and Mixins have been
invented.
But both of them are complex and hard to understand. PHP5 has been
explicitly
designed with the clean and successful model of Java in mind:
single inheritance, but multiple interfaces. This decision has been
taken
to avoid the known problems of for example C++. The presented
approaches
have
been designed to avoid those problems and to enable designers to
build
conceptually clean class hierarchies without the need to consider
code reuse
or complexity problems, but focusing on the real problem domain and
maintainability instead.
Limitations to Reuse in Single Inheritance Languages
There are several issues with reuse in PHP. To achieve as much
reuse as
possible you will probably move methods as high as possible in your
inheritance
hierarchy. At this point, there is a trade-off between conceptual
consistency
and reuse, because classes starts to have methods they do not need.
So, when
it
is decided that the conceptual consistency is more valuable because
of
understandability of the class model, code duplication is caused or
needs to
be
worked around by e.g. delegation, which is not always as nice as
method
implemented in the class tree.
Beside conceptual issues, there are problems with third-party code
you can
not
or might not want to modify. The following code illustrates the
current
implementation of an extended version of the PHP reflection API which
provides
detailed access to doc comment blocks. ``ReflectionMethod`` and
``ReflectionFunction`` are classes from the reflection API and have
to be
extended with exactly the same code. In this case it is impossible
to change
the classes itself, because they are not under our control i.e.
they are
implemented in C as part of the language.
::
?php
class ezcReflectionMethod extends ReflectionMethod {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
/* ... */
function getReturnType() { /*1*/ }
function
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Hi! So lets warm this up again. HEAD is for development .. so lets get this into HEAD so that it will be part of the next bigger PHP release for sure! Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits and waits to be merged. :) I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On 14.10.2009, at 22:03, Stanislav Malyshev wrote: Hi! So lets warm this up again. HEAD is for development .. so lets get this into HEAD so that it will be part of the next bigger PHP release for sure! Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits and waits to be merged. :) I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. i think Stefan is fully aware of that probably there will be a discussion first .. but i think we all agree that this feature is very high on the list of what people want and therefore i wanted to get this discussion going, so that after its concluded traits can be commited to HEAD. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
I'm very concerned about the practical consequences of introducing traits without state. Lacking support for properties (state) in traits, programmers will immediately start hacking properties in anyway. I see two approaches: A. They could do this using static hashes in global variables or a separate class. The result is a garbage collection failure as these references to $this will never go away. Designed-in GC failures are unacceptable post PHP 5.3. B. PHP allows you to define properties at runtime. That is, you can write: $this-title = 'my title'; Without declaring var $title; at the class level. But PHP 6 seems to be moving toward more strictness, not less, and this style encourages the use of undeclared variables with the resulting potential for missed bugs. * * * Also, the 'instead' keyword is baffling - it could mean replace A with B or replace B with A depending on how you place your mental comma - I much prefer the assignment syntax alternative, or 'insteadof' which is unambiguous. On Wed, Oct 14, 2009 at 4:07 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 14.10.2009, at 22:03, Stanislav Malyshev wrote: Hi! So lets warm this up again. HEAD is for development .. so lets get this into HEAD so that it will be part of the next bigger PHP release for sure! Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits and waits to be merged. :) I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. i think Stefan is fully aware of that probably there will be a discussion first .. but i think we all agree that this feature is very high on the list of what people want and therefore i wanted to get this discussion going, so that after its concluded traits can be commited to HEAD. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
I was pointed to the http://wiki.php.net/rfc site the other day at the
ATLPHP user group and found the traits and related RFC's.
I just read the RFC on grafts and traits for PHP. Great ideas! There
is one other thing I'd like you to take a look at as well though,
that's very useful.
Objective-C has a construct called a Category. It is similar in
functionality to Traits, but has an important and useful distinction
in the way that the additional functions are injected into the
target class in practice.
Categories can be applied to existing classes from *outside* the class
definition. This is a very useful pattern in that it allows users of
classes to inject functionality without subclassing, AND without
touching the source of the target class.
class Helloworld
{
public function sayHello() { print HELLO; }
}
category HelloworldExtras on Helloworld
{
public function sayWorld() { print World; }
}
$h = new Helloworld;
$h-sayWorld(); // print WORLD
This is extremely beneficial for lightweight extension of classes
without subclassing.
Other than this, it is identical to traits.
I was discussing this off-list with Stefan, and he asked me how it
would work with autoloading, which has led me to add one more piece to
the idea, which is a way to tell the compiler to load your category. I
haven't thoroughly read all of the namespace RFCs so this may conflict
with the use keyword, but something like:
use HelloworldExtras;
Would be a lightweight way to make sure that the autoloader would add
the category into the runtime.
Looking forward to your comments. Also, I will be at php|works in
Atlanta Thursday and Friday if anyone is interested in discussing this
in person!
Regards,
Alan Pinstein
Regards,
Alan Pinstein
http://phocoa.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
class Helloworld
{
public function sayHello() { print HELLO; }
}
category HelloworldExtras on Helloworld
{
public function sayWorld() { print World; }
}
$h = new Helloworld;
$h-sayWorld(); // print WORLD
This is extremely beneficial for lightweight extension of classes
without subclassing.
This feature is identical to the C# .NET Extension methods. The best use
of it is for selectively extending the primitive type classes on the fly
with methods you need (string, int, array, etc.).
The irony in this is, in PHP the primitive types are not OOP capable, so
with this in mind I wonder how much this functionality would serve to make
the life of people easier, and how much of it will be just the rope they
need to hang themselves. The concept of categories and extensions is not as
popular to the average developer as say classes and interfaces.
Also we can't overload use for this as use specifically only imports
symbol names, not actual code, into the environment. It doesn't have the
knowledge of whether something is a namespace, or a class, or a category, so
to know how to trigger autoload.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
