Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On Thu, Oct 15, 2009 at 10:42 AM, Stefan Marr 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
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 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
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
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
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 : > 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 > 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
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 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
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
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 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 :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. :: Thus, eventually, we end up with much duplicated code in both classes extending the original extension classes. Which Opportunities Does PHP Has? - For the sake of distinction and discussion, the two approaches are named differently. The idea of *Traits* fo
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 :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. :: Thus, eventually, we end up with much duplicated code in both classes extending the original extension classes. Which Opportunities Does PHP Has? - For the sake of distinction and discussion, the two approaches are named differently. The idea of *Traits* for PHP has been already proposed in a former RFC_. This RFC introduces in addition the notion of *Grafts* (the term is borrowed from `agrarian cultivation`_). A *Trait* is an unit of
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
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