Re: [PHP-DEV] RFC: Traits for PHP
[EMAIL PROTECTED] wrote: Hi, [..] Request for Comments: Traits for PHP [..] If it doesn't affect performance *MUCH* then I'm all for it ! It can bring better structure for complex designs. Also by reusing, I'm assuming less memory will be needed for the code base which is beneficial. - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On 18/02/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.
Thank you for your attention and I'm looking forward to hear your comments
:)
Kind Regards
Stefan
Request for Comments: Traits for PHP
:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
... contents::
This RFC will discuss at first the motivation for Traits describing the
rationals
and presenting a short real world use case. The main part will describe the
concept of Traits in detail using the syntax for Traits implemented in a
patch
which is part of this proposal. In the end, the URL of the patch and
additional resources about Traits are given.
Introduction
*Traits* is a mechanism for code reuse in single inheritance languages such
as PHP. A Trait is intended to reduce some limitations of single inheritance
by enabeling a developer to reuse sets of methods freely in several
independent
classes living in different class hierarchies.
The semantics of the combination of Traits and classes is defined in a way,
which reduces complexity and avoids the typical problems associated with
multiple
inheritance and Mixins.
They are recognized for their potential in supporting better composition
and reuse, hence their integration in newer versions of languages
such as Perl 6, Squeak, Scala, Slate and Fortress.
Traits have also been ported to Java and C#.
Why do we need Traits?
--
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++.
Traits have been invented to avoid those problems, too. They enable designer
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.
Traits: A Mechanism for Fine-grained Reuse
==
A Trait is a unit of reuse much like a class, but only intended to group
functionality in a fine-grained and consistent way. It is not possible to
instantiate a Trait on its own. It is an addition to traditional inheritance
and enables horizontal composition of behavior.
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 some situations it
would be possible to add a common base class, but in this case it is
impossible, because the extended classes are not under our control, i.e.,
they
are implemented in third party code or even in C, like it is the case here.
::
?php
class ezcReflectionMethod extends ReflectionMethod {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
?
With Traits it is possible to refactor this redundant code out.
::
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
}
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
use ezcReflectionReturnInfo;
/* ... */
}
?
This is just a small example of what Traits are useful for.
The next sections will discuss on more advanced techniques and describe how
the
current implementation of Traits for PHP works.
The Flattening Property
---
As already mentioned, multiple inheritance and Mixins are complex
mechanisms.
Traits are an
Re: [PHP-DEV] PHP mail() header patch for SafeMode
Daevel wrote: Hello, without any patch you can modify the sendmail_path parameter and add what you want no ? With mod_php I use this in my virtualhosts : php_admin_value sendmail_path /usr/sbin/sendmail -t -i -f [EMAIL PROTECTED] Yes, I have done this.. but now is the question where is the spamming script? An with CGI module, we already have the username. It should be enough to identify which member is involved ; no ? Yes, but not to identify which the script -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Mark, If it doesn't affect performance *MUCH* then I'm all for it ! It can bring better structure for complex designs. Also by reusing, I'm assuming less memory will be needed for the code base which is beneficial. the current implementation does not save any memory compared to a user-level copy'n'past solution. But there might be the opportunity to optimize the op_array handling. The performance impact is almost the same for a trait usage as for inheritance or interface definitions. The only costly operation is copying the method body from the trait to the class where it is used. But this should be much cheaper than parsing the method for each single class, what would be necessary if one would use a good old copy'n'past approach. Kind Regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error messages for wrong coding
Hello Felipe, Tuesday, February 19, 2008, 4:21:20 AM, you wrote: Hi. Looking on Feature/Change Request, i have seen curious things, and i think that them should issue any error message. See above. --- Bug #39915 - Trying to access the index of an integer should throw a warning: Actual result: $a = 1234; $a[0]; // Not shows error Proposed: - Shows error message (Fatal error, as happens with objects) for integer and float variables. http://felipe.ath.cx/diff/bug39915.diff This patch results in two error message for type long, one complaining about long, one about double. You can use function zend_get_type_by_const() to avoid this. Also make sure that we see the new style message for type bool and anything else that is not handled right now (aka just use default case). --- Bug #42852 - Inconsistent message when creating default object from empty value: Actual result: $obj1-p = 1; // Shows 'Strict Standards ...' $obj2-p[] = 1; // Not shows $a = 1; $obj3-p = $a; // Not shows Proposed: - 'Strict Standards' for all cases. http://felipe.ath.cx/diff/bug42852.diff Looks good. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Larry,
It sounds interesting to me, and I can definitely see the value. I think I'd
suggest having multiple included traits override each other, however, so
that:
trait A {
function foo() { echo A; }
function bar() { echo A; }
}
trait B {
function foo() { echo B; }
function bar() { echo B; }
}
class C {
use A;
use B;
}
$c = new C();
$c-foo(); // prints B since that came second.
$c-bar();
Lets suppose you will need here the A for some domain specific
reason. This is not possible with this mixin semantics, with traits it
is.
That said, the conventional OOP mechanism to get the same result would, I
think, look something like this:
interface iface {
function foo();
function bar();
}
class I implements iface {
function foo() { ... }
function bar() { ... }
}
class A implements iface {
protected $iface;
function __construct() {
$this-iface = new I();
}
function foo() { return $this-iface-foo(); }
function bar() { return $this-iface-bar(); }
}
The class/interface method takes a little more typing and an extra function
call on the stack, but otherwise what is the advantage of Traits over this
method? (Really, I'm genuinely curious.)
Yes, it is the typical delegation pattern. Often used to achieve code
reuse without the need to inherited and clutter up interfaces with
unnecessary stuff.
The advantage of traits here is the preservation of the encapsulation
property of your classes. In many situations you would need to
propagate some state to the delegate which is not a nice thing in all
situations. Instead it would be more elegant to have a method in the
class to preserve encapsulation. The method could be provided by copy
and past, or for consistency and conceptual reasons, by a trait :)
You also note that this mechanism has no runtime impact. That's unfortunate,
because I'd find the ability to add methods to an object at runtime
conditionally based on some other value far more useful in my work. :-)
Especially since, as above, there seems to be a way to implement this
functionality now as-is with a little more typing, yet runtime modification
is still impossible without eval() and similar scary stuff.
Vis, I'd find the following more useful in the code I write:
trait Baby {
function crawl() { ... }
}
trait Teen {
function complain() { ... }
}
class Person {
protected $age;
function __construct($age) {
$this-age = $age;
if ($this-age = 3) {
$this-addTrait('Baby');
}
if ($this-age =13 $this-age =19) {
$this-addTrait(Teen');
}
}
}
$p[1] = new Person(19);
$p[1]-complain();
$p[2] = new Person(1);
$p[2]-crawl();
foreach ($p as $person) {
if ($p instanceof Teen) {
$person-complain();
$person-parent-ground($person);
}
}
I don't know if that's technically not feasible or technically not a Trait
anymore and therefore off topic in this thread (if it is, that's fine, let me
know and I'll shut up about it g), but that strikes me as more useful than
just runtime composition.
This is not Traits anymore, yes :) and as Rasmus suggests there would
be definitely some problems.
But you might be interested in Context-oriented Programming, it tries
to solve such crosscutting concerns you've described in an dynamic
way.
Unfortunately I've no code example at hand but you could have a lock
at http://www.swa.hpi.uni-potsdam.de/cop/
ContextR for Ruby is very promising to solve such problems.
I've had a thought on this for PHP, too. But think there would be many
people against something like dynamic behavior even if this looks
like an oxymoron ;)
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Richard,
A question (and again, no idea on feasibility, internals, etc.).
The above proposal covers adding/overriding internal methods with
external ones. Is it possible to also include additional properties?
If not, then you would have to override the constructor method (this
could be demoted to documentation rather than code then I suppose).
the current proposal does not allow state in your traits.
At the moment the solution would be like this:
trait A {
abstract protected function getFoo();
public function doSomeFoo($bar) {
return $this-getFoo().' baz ' . $bar;
}
}
Traits can defined abstract methods to define a required method. This
abstract methods can be implemented in the class or in an other trait.
There are also notions about stateful traits out there. For instance
Scala does implement them, but state is an additional level of
complexity and I have tried to avoid it in this implementation, since
I have had expected much more complains about the aliasing and exclude
operations and its pretended complexity.
In my opinion stateful traits are the next logical step, but with the
cost for some additional complexity, since you need handle conflicting
properties. (The stateful traits approach is to make it private to a
traits composition, but this might not be obvious to every user.)
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error messages for wrong coding
Em Ter, 2008-02-19 às 12:28 +0100, Marcus Boerger escreveu: This patch results in two error message for type long, one complaining about long, one about double. You can use function zend_get_type_by_const() to avoid this. Also make sure that we see the new style message for type bool and anything else that is not handled right now (aka just use default case). Ooops, I forget that! :D Here's: http://felipe.ath.cx/diff/bug39915.diff Em Ter, 2008-02-19 às 01:25 -0300, Cristian Rodriguez escreveu: you need to handle offset of booleans too.. Oops! Thanks. ... I was sleepy :P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Feb 18, 2008 8:27 PM, [EMAIL PROTECTED] wrote:
Hi,
during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.
Thank you for your attention and I'm looking forward to hear your comments
:)
Kind Regards
Stefan
I know this is in the bike-shed department, but the following syntax
doesn't look very PHP to me:
use B { !bigTalk, talk = bigTalk }
Could we separate exclusions from aliases somehow?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Larry Garfield wrote: On Monday 18 February 2008, Richard Lynch wrote: Why not just allow 'include' here instead? Because include requires the code in question to live in another file, which I don't always want. I'm with Richard Lynch here: Simply allow inclusion. No new language concept, instead an existing one is made more orthogonal which is A Desirable Thing(tm) IMHO. About having it in the same file: You then need to also have the two classes using the Trait to live in the same file (or include_once that file) which is something I'm trying to avoid. I've gotten fond of one class per file for the sake of an autoloader anyway so I don't think separating the common code into a separate file is a big disadvantage. The part about being able to do partial Trait use seems hackish and somewhat complicated to me so I'd rather not have it in the language. It feels a little bit like being able to partially implement an Interface: I think a class should either have a Trait or not. If we're using include to emulate Traits then the same could be accomplished by separating the parts into files (if *really* desired). -1 for Traits as proposed +1 for allowing include in class definitions - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error messages for wrong coding
2008/2/19, Felipe Pena [EMAIL PROTECTED]: Em Ter, 2008-02-19 às 01:25 -0300, Cristian Rodriguez escreveu: you need to handle offset of booleans too.. Oops! Thanks. There is a similar case with unset() an offset of booleans and integers. ?php $foo = true: /* should throw a fatal error, like it does when trying to unset string offsets. actually $foo remains unchanged after unset() (!!) unset($foo[0]); Index: Zend/zend_vm_def.h === RCS file: /repository/ZendEngine2/zend_vm_def.h,v retrieving revision 1.59.2.29.2.48.2.36 diff -u -p -r1.59.2.29.2.48.2.36 zend_vm_def.h --- Zend/zend_vm_def.h 11 Feb 2008 15:46:10 - 1.59.2.29.2.48.2.36 +++ Zend/zend_vm_def.h 19 Feb 2008 14:32:18 - @@ -3281,6 +3281,7 @@ ZEND_VM_HANDLER(75, ZEND_UNSET_DIM, VAR| zend_error_noreturn(E_ERROR, Cannot unset string offsets); ZEND_VM_CONTINUE(); /* bailed out before */ default: + zend_error_noreturn(E_ERROR, Cannot unset %s offsets, zend_get_type_by_const(Z_TYPE_PP(container))); FREE_OP2(); break; } -- http://www.cristianrodriguez.net
Re: [PHP-DEV] RFC: Traits for PHP
Hello Stefan, a userland copy'n'paste does not allow to reuse already compiled opcodes. Traits do at least conceptionally. marcus Tuesday, February 19, 2008, 1:09:24 PM, you wrote: Hi Mark, If it doesn't affect performance *MUCH* then I'm all for it ! It can bring better structure for complex designs. Also by reusing, I'm assuming less memory will be needed for the code base which is beneficial. the current implementation does not save any memory compared to a user-level copy'n'past solution. But there might be the opportunity to optimize the op_array handling. The performance impact is almost the same for a trait usage as for inheritance or interface definitions. The only costly operation is copying the method body from the trait to the class where it is used. But this should be much cheaper than parsing the method for each single class, what would be necessary if one would use a good old copy'n'past approach. Kind Regards Stefan Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hello Rasmus, Tuesday, February 19, 2008, 2:45:15 AM, you wrote: Larry Garfield wrote: You also note that this mechanism has no runtime impact. That's unfortunate, because I'd find the ability to add methods to an object at runtime conditionally based on some other value far more useful in my work. :-) Especially since, as above, there seems to be a way to implement this functionality now as-is with a little more typing, yet runtime modification is still impossible without eval() and similar scary stuff. The idea here is that we want to be able to cache opcodes, classes and functions and optimize them out of the runtime context so the executor can skip creating classes and functions on every single request. A lot of the traffic on this list over the past couple of months seems to ignore this basic premise. Features such as autoload and runtime object manipulation incur a huge performance hit in the sense that they change something that was free before and not only add the cost of the feature itself, but it also means the object in question now can no longer be cached and has to be created on every single request. This doesn't mean we can't consider such features, but people need to also consider the performance implications. For that reason allowing traits in favor of include inside a class body is much better. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Marcus Boerger wrote: Hello Stefan, any dynamic aspect of a class has brought us to problems in inheritance and required us to design the objct/compile model in a way that inheritance often is done at run time. Imo traits are a way out of this. In fact I'd love to issue a deprecated message as soon as class is found outside of a main block. That would mean deprecating autoload as well since autoloading a class is effectively the same as defining it outside of the main block. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hello php,
looks good to me. See more detailed thoughts in separate mail resonses.
The biggest issue I see is finding a syntax everyone likes.
Personally I like everything but one tiny piece, that is you do '!method'
to ignore a method from a trait. Since renaming happens in a php array like
style I would prefer to have that approach apply for ignoring methods as
well. The way to do that imo is 'method=false' or 'method=NULL' which both
should be obvious to PHP programmers that heard about Traits.
Other than that I'd even appriciate it, if we could get this for 5.3. I mean
come on guys it is ready and a very nice solution to the code reuse problem.
marcus
Monday, February 18, 2008, 8:27:00 PM, you wrote:
Hi,
during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.
Thank you for your attention and I'm looking forward to hear your comments
:)
Kind Regards
Stefan
Request for Comments: Traits for PHP
:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
... contents::
This RFC will discuss at first the motivation for Traits describing the
rationals
and presenting a short real world use case. The main part will describe the
concept of Traits in detail using the syntax for Traits implemented in a
patch
which is part of this proposal. In the end, the URL of the patch and
additional resources about Traits are given.
Introduction
*Traits* is a mechanism for code reuse in single inheritance languages such
as PHP. A Trait is intended to reduce some limitations of single inheritance
by enabeling a developer to reuse sets of methods freely in several
independent
classes living in different class hierarchies.
The semantics of the combination of Traits and classes is defined in a way,
which reduces complexity and avoids the typical problems associated with
multiple
inheritance and Mixins.
They are recognized for their potential in supporting better composition
and reuse, hence their integration in newer versions of languages
such as Perl 6, Squeak, Scala, Slate and Fortress.
Traits have also been ported to Java and C#.
Why do we need Traits?
--
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++.
Traits have been invented to avoid those problems, too. They enable designer
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.
Traits: A Mechanism for Fine-grained Reuse
==
A Trait is a unit of reuse much like a class, but only intended to group
functionality in a fine-grained and consistent way. It is not possible to
instantiate a Trait on its own. It is an addition to traditional inheritance
and enables horizontal composition of behavior.
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 some situations it
would be possible to add a common base class, but in this case it is
impossible, because the extended classes are not under our control, i.e.,
they
are implemented in third party code or even in C, like it is the case here.
::
?php
class ezcReflectionMethod extends ReflectionMethod {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
class ezcReflectionFunction extends ReflectionFunction {
/* ... */
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
/* ... */
}
?
With Traits it is possible to refactor this redundant code out.
::
?php
trait
Re: [PHP-DEV] _REQUEST and variable_order
I would like to see $_REQUEST be just GET | POST That's what ini-recommended is configured for. I also see no reason to not keep $_GET if 'G' is missing from GPC ordering, so that would be a fine second choice. That changes semantics of existing switch, so I don't feel comfortable to do such change... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hello Rasmus, not really. We can have a table that keeps track of which class was declared in what file. Then we could actually break down files into class definitions and only import the requested part. In a perfect world each class would be in its own file. A file would only create a single class and nothing more or contain the code to generate output, probably some short, flat procedural code. Then each of these files would get compiled and cached. And loaded from those output generating files... marcus Tuesday, February 19, 2008, 4:59:19 PM, you wrote: Marcus Boerger wrote: Hello Stefan, any dynamic aspect of a class has brought us to problems in inheritance and required us to design the objct/compile model in a way that inheritance often is done at run time. Imo traits are a way out of this. In fact I'd love to issue a deprecated message as soon as class is found outside of a main block. That would mean deprecating autoload as well since autoloading a class is effectively the same as defining it outside of the main block. -Rasmus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On 19.02.2008, at 15:32, Marcus Boerger wrote: In fact I'd love to issue a deprecated message as soon as class is found outside of a main block. err .. deprecated? as in you want to deprecate the possibility entirely? or you just want to hin to the user that its a bad idea .. (not sure if even E_STRICT would be a good fit there). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Annotations
On 19.02.2008, at 00:22, clynx wrote: I have thought about a new feature for some days now. The initial plan was to create a new keyword deprecated which should simply trigger a warning when the right error level was set. This could have been combined with the E_DEPRECATED level from 5.3 (maybe, otherwise E_STRICT). The goal was to have a possibility for PHP projects to mark some functions, classes or methods as no longer recommend to use. The first step would be to set this new keyword, and after some releases the developers could remove this item. Just as it is handled in PHP itself. I know that there is a phpDoc property for this, but when you execute your code you'll never realize that. Well the topic of annotations is a big one in its own right. However once we have E_DEPRECATED you can at least use trigger_error() to get your desired effect. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hello Lukas, it doesn't work with opcode cashes. So I want at least an E_STRICT here. And yes I mean what I wrote. That's why I wrote it. marcus Tuesday, February 19, 2008, 6:40:08 PM, you wrote: On 19.02.2008, at 15:32, Marcus Boerger wrote: In fact I'd love to issue a deprecated message as soon as class is found outside of a main block. err .. deprecated? as in you want to deprecate the possibility entirely? or you just want to hin to the user that its a bad idea .. (not sure if even E_STRICT would be a good fit there). regards, Lukas Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Role model RFC
On Feb 19, 2008 2:09 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hi,
I really like what Stefan did here with his traits RFC. Very solid
work, even if there are still some people not convinced if they want
this feature in, I have seen little complaints about the way this
proposal was made. Quite the contrary actually. I would like this kind
of detailed thought to become more the norm. Even if at the very
beginning of an idea this quality may not be immediately attainable,
it should be the goal. So for every idea we should have at least
someone who tries to bring the proposal to this kind of level as the
discussions progress.
For this proposal I would hope that it would be put on some host we
can trust to not disappear and be updated with the feedback. I am
still dreaming of a php.net wiki for this kind of stuff. If interested
I do of course offer wiki.pooteeweet.org to host these RFC's for the
time being. Using php.net/reST has the draw back of requiring
cvs.php.net karma for maintenance, which would be problematic for new
comers, unless we can do karma on a per file level for this?
I'd certainly be a +1 for a wide-open Wiki on php.net for this and
similar activities. It's been mentioned for quite some time, and it
seems as though - despite the fact that PHP drives the most popular
Wiki software - we're the last to adopt it. In any case, keeping it
open means that ALL people involved and with more than just a passing
interest can get involved in the C part of the RFC.
If it goes through, feel free to count me in as a volunteer to
moderate submissions, vandalism, and such.
--
/Dan
Daniel P. Brown
Senior Unix Geek
? while(1) { $me = $mind--; sleep(86400); } ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Role model RFC
Hi, I really like what Stefan did here with his traits RFC. Very solid work, even if there are still some people not convinced if they want this feature in, I have seen little complaints about the way this proposal was made. Quite the contrary actually. I would like this kind of detailed thought to become more the norm. Even if at the very beginning of an idea this quality may not be immediately attainable, it should be the goal. So for every idea we should have at least someone who tries to bring the proposal to this kind of level as the discussions progress. For this proposal I would hope that it would be put on some host we can trust to not disappear and be updated with the feedback. I am still dreaming of a php.net wiki for this kind of stuff. If interested I do of course offer wiki.pooteeweet.org to host these RFC's for the time being. Using php.net/reST has the draw back of requiring cvs.php.net karma for maintenance, which would be problematic for new comers, unless we can do karma on a per file level for this? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Role model RFC
On Feb 19, 2008 2:09 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, I really like what Stefan did here with his traits RFC. Very solid work, even if there are still some people not convinced if they want this feature in, I have seen little complaints about the way this proposal was made. Quite the contrary actually. I would like this kind of detailed thought to become more the norm. Even if at the very beginning of an idea this quality may not be immediately attainable, it should be the goal. So for every idea we should have at least someone who tries to bring the proposal to this kind of level as the discussions progress. Most definitely, thanks to Stefan for this. I have rarely seen such RFC in PHP lately. This is.. wow, from simple example to a bit more complex and real life examples, simple texts, the reason why we need this and a bit more about MI. The external links to further readings on the subject are great and the thesis is even better (A bit long but very interesting). I think this can make a lot of good to PHP's RFC process if handled correctly. Let's just hope we do it correctly :) For this proposal I would hope that it would be put on some host we can trust to not disappear and be updated with the feedback. I am still dreaming of a php.net wiki for this kind of stuff. If interested I do of course offer wiki.pooteeweet.org to host these RFC's for the time being. Using php.net/reST has the draw back of requiring cvs.php.net karma for maintenance, which would be problematic for new comers, unless we can do karma on a per file level for this? Wiki is such a great idea, what were the (political?) reasons for not having it ? No one to maintain it ? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Stefan,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
I'm not sure if the use-keyword is a good idea as namespaces are already
used. If we use use for traits, maybe going back to import for
namespaces would be the way to go.
cu, Lars
--
Lars Strojny
Senior Software Developer MediaVentures GmbH (http://mediaventures.de)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
Hello Lars,
we could even go for include here if we wanted to avoid use as much as
adding a new keyword. Personally I don't mind using keywords for different
stuff as long as it cannot conflict. That is in this case true for both
include and use.
marcus
Tuesday, February 19, 2008, 9:31:29 PM, you wrote:
Hi Stefan,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
I'm not sure if the use-keyword is a good idea as namespaces are already
used. If we use use for traits, maybe going back to import for
namespaces would be the way to go.
cu, Lars
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Marcus, Am Dienstag, den 19.02.2008, 17:58 +0100 schrieb Marcus Boerger: [...] looks good to me. See more detailed thoughts in separate mail resonses. The biggest issue I see is finding a syntax everyone likes. I can't agree more. Personally I like everything but one tiny piece, that is you do '!method' to ignore a method from a trait. Since renaming happens in a php array like style I would prefer to have that approach apply for ignoring methods as well. The way to do that imo is 'method=false' or 'method=NULL' which both should be obvious to PHP programmers that heard about Traits. The irritating thing is that currently it would be null = 'oldmethod'. This is what I would critisize in general. I would prefer 'oldMethodName' = 'newMethodName' instead. 'oldMethodName' = null would be really cool. Other than that I'd even appriciate it, if we could get this for 5.3. I mean come on guys it is ready and a very nice solution to the code reuse problem. [...] This would be a killer feature for 5.3! How realistic is it to get this in? [...] cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
On Tue, 19 Feb 2008 13:23:57 +0100, Stefan Marr [EMAIL PROTECTED] wrote: Traits can defined abstract methods to define a required method. This abstract methods can be implemented in the class or in an other trait. There are also notions about stateful traits out there. For instance Scala does implement them, but state is an additional level of complexity and I have tried to avoid it in this implementation, since I have had expected much more complains about the aliasing and exclude operations and its pretended complexity. In my opinion stateful traits are the next logical step, but with the cost for some additional complexity, since you need handle conflicting properties. (The stateful traits approach is to make it private to a traits composition, but this might not be obvious to every user.) Kind Regards Stefan (Sorry for the double email; I meant to send this to the list.) So if the Trait is not stateful, what is the advantage over delegation? That was cited in an earlier email as a shortcoming of delegation, but if the Traits implementation doesn't address it either except through a getter/setter, then it's still functionally equivalent to delegation. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Marcus, Am Dienstag, den 19.02.2008, 21:42 +0100 schrieb Marcus Boerger: [...] we could even go for include here if we wanted to avoid use as much as adding a new keyword. Personally I don't mind using keywords for different stuff as long as it cannot conflict. That is in this case true for both include and use. I'm not sure about this. I can imagine it would not be really intuitive why someone use a namespace and use a trait while he also includes a file and includes a trait. So my only concern is that this great language feature would be harder to understand as it must be. cu, Lars -- Lars Strojny Senior Software Developer MediaVentures GmbH (http://mediaventures.de) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
Hi Marcus,
Hi Troels,
The biggest issue I see is finding a syntax everyone likes.
Well, lets try some variations.
Since renaming happens in a php array like
style I would prefer to have that approach apply for ignoring methods as
well. The way to do that imo is 'method=false' or 'method=NULL' which both
should be obvious to PHP programmers that heard about Traits.
At first I'll have to make this clear. Aliasing != renaming.
It is not renaming operation. Aliasing will give you an additional
name for a method body.
By example:
trait Foo {
public function foo() {echo 'foo';}
}
class FooFoo {
use Foo {
bar = foo
}
}
This will eventually result in the following class at runtime:
class FooFoo { /* RUNTIME */
public function foo() { echo 'foo';}
public function bar() { echo 'foo';}
}
My idea behind this notation was the key = value thing
use Trait {
additionalMethodName = method
}
but may be we should use a keyword here which will be more clear.
Troels ask for a separation of aliases and exclusions.
Here are some notation proposals:
[1] Explicit Except/Without List
use Trait except foo1, foo2 {
bar = foo1
}
the keyword except could may be replaced by exceptfor or without if it
fits better.
[2a] ! is not readable -- except
use Trait {
except foo1, foo2;
bar = foo1
}
[2b] ! is not readable -- without
use Trait {
without foo1;
without foo2;
bar = foo1;
}
[Aa] Aliasing is not obvious
use Trait {
bar is foo1; //aliasMethod is method
}
[Ab] Aliasing is not obvious
use Trait {
bar from foo1; //aliasMethod from method
}
I'm not sure about Aa and Ab because they do not read well in my opinion.
What do you think?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
firstly, I'd like to reiterate the general sentiment
that Stefans RFC is blinding! (that's a good thing in this context ;-)
Marcus Boerger schreef:
Hello Lars,
we could even go for include here if we wanted to avoid use as much as
adding a new keyword. Personally I don't mind using keywords for different
stuff as long as it cannot conflict. That is in this case true for both
include and use.
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
Jack possesses a trait
a person coming accross 'use' or 'include' in the context of
trait attribution may either make assumptions or become confused as to
possible changes/additions to the use and/or include functionality, a
new keyword that aptly describes the intention will more likely force
users to actually find out what it means.
an another alternative might be 'applies' - which doesn't fit the
natural language usage of 'trait' but does succintly describe what is happening.
just a thought.
marcus
Tuesday, February 19, 2008, 9:31:29 PM, you wrote:
Hi Stefan,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
I'm not sure if the use-keyword is a good idea as namespaces are already
used. If we use use for traits, maybe going back to import for
namespaces would be the way to go.
cu, Lars
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
In case anyone is really excited about traits and traits don't make it in soon, I'll point out that something similar has been available in php for years. We've been implementing traits based on the fact that $this has a different meaning in php than in other languages. In php, $this is the most recent object context. So... it's easy to create a trait class and make calls to it from your non-trait class using :: syntax. - calls within the trait class automatically go back to the non-trait class. This makes the purists shudder and they added a STRICT message for it. (If you're a purist please don't bother replying with how evil I am. I already know this makes your stomach turn.) It obviously isn't as clean as a well defined trait feature (or doing a re-architecture of your app to elimate the need), but if you need traits today, this may work for you. - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Stanislav, traits the included trait is using). Ok this is the scope. Now we would need to adjust all those method bodies, find all method calls on $this-oldMethodName() and change them to $this-newMethodName(). You can't - PHP has dynamic method resolution (think $this-$foo()). Also, it has callbacks - what happens if method is registered as callback is renamed? thanks, this is very good reason not to allow renaming, but aliasing. :) Kind Regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
traits the included trait is using). Ok this is the scope. Now we would need to adjust all those method bodies, find all method calls on $this-oldMethodName() and change them to $this-newMethodName(). You can't - PHP has dynamic method resolution (think $this-$foo()). Also, it has callbacks - what happens if method is registered as callback is renamed? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Personally I like everything but one tiny piece, that is you do '!method' to ignore a method from a trait. Since renaming happens in a php array like style I would prefer to have that approach apply for ignoring methods as well. The way to do that imo is 'method=false' or 'method=NULL' which both should be obvious to PHP programmers that heard about Traits. The irritating thing is that currently it would be null = 'oldmethod'. This is what I would critisize in general. I would prefer 'oldMethodName' = 'newMethodName' instead. 'oldMethodName' = null would be really cool. It is not renaming is aliasing :) Feels like I should give some thoughts on why renaming is not a good idea. The question is, how should renaming work and in which scope is it applied? Renaming would imply to adjust all references to a method name in all methods of one composition. A composition are all methods flattened into a class from one specific trait usage (including all methods from traits the included trait is using). Ok this is the scope. Now we would need to adjust all those method bodies, find all method calls on $this-oldMethodName() and change them to $this-newMethodName(). Think this would be possible, yes. But think the original traits idea goes a step further. By excluding a method from a trait it is possible to mesh traits together and build compositions where the result is a interleaving construct, like gears. The problem with renaming is, you will have no chance to achieve such a meshed situation without additional glue code. Excluding a trait method can be thought of as punching a hole into your class which is either filled by another trait or by a method defined in the class itself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Stefan Marr wrote:
Hi Stanislav,
traits the included trait is using). Ok this is the scope. Now we
would need to adjust all those method bodies, find all method calls on
$this-oldMethodName() and change them to $this-newMethodName().
You can't - PHP has dynamic method resolution (think $this-$foo()).
Also, it has callbacks - what happens if method is registered as
callback is renamed?
thanks, this is very good reason not to allow renaming, but aliasing.
:)
Aliasing doesn't make a lot of sense, as you can always :
function newMethod() {
return $this-oldMethod();
}
just seems like unneeded complexity, without a clear benefit..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Feb 19, 2008 9:54 PM, Jochem Maas [EMAIL PROTECTED] wrote:
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
Jack possesses a trait
I prefer ``without`` over ``except``, because ``except`` is close to
``exception`` and because it has a different meaning in other
languages (Eg. ``catch``).
I'm not sure if the use-keyword is a good idea as namespaces are already
used. If we use use for traits, maybe going back to import for
namespaces would be the way to go.
I agree that ``use`` is a bad choice, because of the nameclash with
the namespaces syntax (pun intended). ``possesses`` is hideous, but
``exhibit`` isn't too bad.
On Feb 19, 2008 10:02 PM, Stefan Marr [EMAIL PROTECTED] wrote:
Here are some notation proposals:
(snip)
I'm not sure about Aa and Ab because they do not read well in my opinion.
What do you think?
[Ac] How about this:
class FooFoo {
exhibit Traitor {
alias foo as bar;
}
}
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Evert,
Aliasing doesn't make a lot of sense, as you can always :
function newMethod() {
return $this-oldMethod();
}
Don't think so.
You do use aliasing to handle conflicts and in the case of a conflict
there is no oldMethod.
trait A {
public function foo() {echo 'foo';}
}
trait B {
public function foo() {echo 'fooBar';}
}
class MyClass {
use A;
use B {
!foo, fooBar = foo
}
}
The result will be at runtime:
class MyClass {
public function foo() {echo 'foo';}
public function foo() {echo 'fooBar';}
}
Here you can't do something like this:
class MyClass {
use A;
use B;
}
since eventually there wont be any method in MyClass.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Larry, So if the Trait is not stateful, what is the advantage over delegation? That was cited in an earlier email as a shortcoming of delegation, but if the Traits implementation doesn't address it either except through a getter/setter, then it's still functionally equivalent to delegation. Think the difference is not the functional part here but the conceptional goal which is achieved. Delegation has still a strong right to exist even with traits. The idea of delegation is to reuse a complete entity. May be not the best example but still a good one is the OO Stack build from a linked list. You did like to reuse the list as a container for the stack data. It is full-fledged object here, which will do something for you. But in situations where you have a strong coherence of the state and the behavior you need and the state may consist of several properties, the natural thing would be to implement the behavior in a method in this class, because delegation would require you to make this properties accessible by getters/setters or have methods with many parameters. Here the real question is, does the delegate has a right to exist without this client? Are there any other clients using this class, or is it more appropriated to merge it directly into this class? This questions could only be answered seriously for a specific case. Traits are meant to simplify the code reuse for single methods or groups of methods while delegation allows reuse of complete autonomous entities. Well, think the above is only true in a world of perfect design ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Feb 19, 2008 10:51 PM, Evert | Rooftop [EMAIL PROTECTED] wrote:
Aliasing doesn't make a lot of sense, as you can always :
function newMethod() {
return $this-oldMethod();
}
just seems like unneeded complexity, without a clear benefit..
I believe the idea was to resolve nameclashes.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::
?php
interface IHello {
public function sayHello();
}
trait SayHello implements IHello {
public function sayHello() {
echo 'Hello World!';
}
}
class MyHelloWorld {
use SayHello;
}
$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool(true)
We have discussed that in IRC a bit and a lot of questions remain. The
most important issue to me how to handle interface implementations in
cases where methods from the interface implementing trait are renamed in
the trait consumer class.
I would propose to not overcomplicate things here and I see no real
advantage in allowing traits to implement interfaces. I think also for
the sake of conceptual integrity separating interfaces clearly from
traits is a good idea: interfaces define structure while traits are
function buckets. A class may use traits, may implement interfaces and
may extend another class. This paradigm is pretty easy to explain to the
user.
cu, Lars
--
Lars Strojny
Senior Software Developer MediaVentures GmbH (http://mediaventures.de)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
2008/2/19, Lars Strojny [EMAIL PROTECTED]:
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::
?php
interface IHello {
public function sayHello();
}
trait SayHello implements IHello {
public function sayHello() {
echo 'Hello World!';
}
}
class MyHelloWorld {
use SayHello;
}
$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool(true)
We have discussed that in IRC a bit and a lot of questions remain. The
most important issue to me how to handle interface implementations in
cases where methods from the interface implementing trait are renamed in
the trait consumer class.
Well, it is aliasing, not renaming.
Think only the exclusion of a method will break the interface, but
since the interface is propagated to the class the class has to take
care that it is implemented properly and an error will be raised if it
is not implemented correctly at compile time.
Let say I modify the example like this:
class MyHelloWorld {
use SayHello {
!sayHello
}
}
the compiler will give an error that sayHello is missing since
MyHelloWorld states it is implementing IHello.
I would propose to not overcomplicate things here and I see no real
advantage in allowing traits to implement interfaces. I think also for
the sake of conceptual integrity separating interfaces clearly from
traits is a good idea: interfaces define structure while traits are
function buckets. A class may use traits, may implement interfaces and
may extend another class. This paradigm is pretty easy to explain to the
user.
Yes it is definitely a conceptual problem to propagate interfaces,
because the notation does not imply this behavior and you can not see
the interfaces added by the trait.
Therefore, I'm with you, interface propagation might be a point to not
be included.
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi,
Lars Strojny schreef:
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::
?php
interface IHello {
public function sayHello();
}
trait SayHello implements IHello {
public function sayHello() {
echo 'Hello World!';
}
}
class MyHelloWorld {
use SayHello;
}
$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool(true)
We have discussed that in IRC a bit and a lot of questions remain. The
most important issue to me how to handle interface implementations in
cases where methods from the interface implementing trait are renamed in
the trait consumer class.
I would propose to not overcomplicate things here and I see no real
advantage in allowing traits to implement interfaces. I think also for
the sake of conceptual integrity separating interfaces clearly from
traits is a good idea: interfaces define structure while traits are
function buckets. A class may use traits, may implement interfaces and
may extend another class. This paradigm is pretty easy to explain to the
user.
if a trait would could contain all the methods required to implement an
interface
and a class uses it (the trait) and implements the relevant interface would it
(the interface) be satified?
also might it be an idea to allow a trait to specify that it implements an
interface
for the purposes of development (errors triggered due to incorrect/incomplete
implementation)
BUT not have the interface be carried to any classes that use the trait? ...
classes
would have to explicitly state that they implement the interface and the fact
that they
use a trait to do so would be irrelevant as far as 'where' the method came from.
interface iFoo {
function doFoo();
}
// causes a compile time error due to missing function
//
trait tOneFoo implements iFoo {
function doBar() { echo hello; }
}
// no compile time error
//
trait tTwoFoo implements iFoo {
function doFoo() { echo hello; }
}
// using a trait that implements something without actually
// taking on the implementation
//
class cOneFoo {
uses tTwoFoo;
}
// any iFoo method exclusion, aliasing, renaming
// in the following class would cause a compile time error
// due to missing iFoo function unless the class itself
// defined the method(s) in question
//
class cTwoFoo implements iFoo {
uses tTwoFoo;
}
$one = new cOneFoo;
$two = new cTwoFoo;
// outputs: false, true
var_dump( ($one instanceof iFoo), ($one instanceof iFoo) );
something like the above might offer developers desired OO strictness
without actually blurring the boundaries between trait and interface
conceptually.
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
most important issue to me how to handle interface implementations in
cases where methods from the interface implementing trait are renamed in
the trait consumer class.
Renaming poses problem not only with interfaces. Imagine trait having
these methods:
function add($key, $value) { ... }
function delete($key) { ... }
function replace($key, $value) { $this-delete($key); $this-add($key,
$value); }
What happens if add() is renamed or replaced with function from other
trait/interface or dropped?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Jochem,
Am Mittwoch, den 20.02.2008, 00:06 +0100 schrieb Jochem Maas:
[...]
if a trait would could contain all the methods required to implement
an interface and a class uses it (the trait) and implements the
relevant interface would it (the interface) be satified?
Yes. The following should work:
interface IFoo {
public function method();
}
trait TFoo {
public functin method() {
echo Hello World!;
}
}
class CFoo implements IFoo
{
use TFoo;
}
This would be fine.
also might it be an idea to allow a trait to specify that it
implements an interface for the purposes of development (errors
triggered due to incorrect/incomplete implementation)
BUT not have the interface be carried to any classes that use the
trait?
I don't see any sence in it. Why should one generalize an interface of a
trait?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
As the $this is resolved after flattening, the delete()-method of the current class is used, isn't it? Exactly, and who knows if it does whatever replace() needs it to do? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Stas, Am Dienstag, den 19.02.2008, 15:59 -0800 schrieb Stanislav Malyshev: [...] Exactly, and who knows if it does whatever replace() needs it to do? As traits are fixed compositions in contrast to the dynamic concept mixin it's in the hands of the developer to let replace() do the right thing [tm] as the developer has all the information he needs to decide what replace() needs to do when writing code. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
Lars Strojny schreef:
Hi Jochem,
Am Mittwoch, den 20.02.2008, 00:06 +0100 schrieb Jochem Maas:
[...]
if a trait would could contain all the methods required to implement
an interface and a class uses it (the trait) and implements the
relevant interface would it (the interface) be satified?
Yes. The following should work:
interface IFoo {
public function method();
}
trait TFoo {
public functin method() {
echo Hello World!;
}
}
class CFoo implements IFoo
{
use TFoo;
}
This would be fine.
also might it be an idea to allow a trait to specify that it
implements an interface for the purposes of development (errors
triggered due to incorrect/incomplete implementation)
BUT not have the interface be carried to any classes that use the
trait?
I don't see any sence in it. Why should one generalize an interface of a
trait?
I don't suppose you would, I thinking more along the lines of having it
a developer tool - using implements on a trait would force the developer to
put in the correct methods, it might help a team that had say 1 interface, 2
traits
(which both contain a set of methods that satify said interface) and a large
number
of classes that implement one or other of the traits ... having the trait state
that it's capable of handling an implementation might save some WTF because
compile time errors would happen on the trait if it broke the interface
signature,
rather than on the class ... an interface related error on the class it might
not be
obvious to the developer with regard to the fact that the/a trait the class is
using
was for the purpose of satifying an interface the class states it is
implementing.
I'm thinking that it will proably occur quite often that a fairly simple
interface
will be 'covered' by a trait and that said trait would be used solely for
satifying
said interface implementation and used as such for classes that wish to
implement
said interface.
to quote Troels:
Class inheritance (The ``extends`` keyword) inherits type
+ implementation. Interface inheritance (The ``implements`` keyword)
inherits type (but not implementation). Traits fill the missing hole
by allowing inheritance of implementation, but not type.
that sounds more than reasonable, but it might be worth offering an aid
to developers during the compile time phase, with regard to the 'link' between
a trait and an interface (assuming you would agree that it's not unlikely that
the two would be used in tandem on occasion) without imposing/implying anything
at run time (i.e. a trait may implement an interface to ensure correctness but
that has no effect on any class that uses it, classes must explicitly state it's
intention to implement an interface)
I may have said something stupid - but given the ability of your average php
user
to stupid things with the functionality offered to him/her, my comments might
aid in thrashing out such details in order to limit a user's ability to do
stupid
things :-)
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Role model RFC
Lukas Kahwe Smith wrote: Hi, I really like what Stefan did here with his traits RFC. Very solid work, even if there are still some people not convinced if they want this feature in, I have seen little complaints about the way this proposal was made. Quite the contrary actually. I would like this kind of detailed thought to become more the norm. Even if at the very beginning of an idea this quality may not be immediately attainable, it should be the goal. So for every idea we should have at least someone who tries to bring the proposal to this kind of level as the discussions progress. For this proposal I would hope that it would be put on some host we can trust to not disappear and be updated with the feedback. I am still dreaming of a php.net wiki for this kind of stuff. If interested I do of course offer wiki.pooteeweet.org to host these RFC's for the time being. Using php.net/reST has the draw back of requiring cvs.php.net karma for maintenance, which would be problematic for new comers, unless we can do karma on a per file level for this? regards, Lukas What kind of traffic would the wiki attract (rough ballpark) I've got a few high spec dedicated servers, and could possibly donate one to the cause - thats if a single server would be up to the task. regards Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi Stas,
Am Dienstag, den 19.02.2008, 14:58 -0800 schrieb Stanislav Malyshev:
[...]
Renaming poses problem not only with interfaces. Imagine trait having
these methods:
function add($key, $value) { ... }
function delete($key) { ... }
function replace($key, $value) { $this-delete($key); $this-add($key,
$value); }
What happens if add() is renamed or replaced with function from other
trait/interface or dropped?
As the $this is resolved after flattening, the delete()-method of the
current class is used, isn't it?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
Hi! As traits are fixed compositions in contrast to the dynamic concept mixin it's in the hands of the developer to let replace() do the right thing [tm] as the developer has all the information he needs to decide what replace() needs to do when writing code. replace() does the right thing - it uses add() and delete(). The problem here is that current proposal allows any user to yank the ground from under the feet of the trait API creator and replace various bits of the class with any other functionality without any regard for the interdependency between them, so either each function in the traits should be completely self-reliant and never use other functions - which prevents one from create complete non-trivial APIs - or every rename should be painfully verified with original trait developer or against the actual source code, breaking the abstraction. Both don't seem too practical to me. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi, Am Dienstag, den 19.02.2008, 16:37 -0800 schrieb Stanislav Malyshev: [...] replace() does the right thing - it uses add() and delete(). The problem here is that current proposal allows any user to yank the ground from under the feet of the trait API creator and replace various bits of the class with any other functionality without any regard for the interdependency between them, so either each function in the traits should be completely self-reliant and never use other functions - which prevents one from create complete non-trivial APIs - or every rename should be painfully verified with original trait developer or against the actual source code, breaking the abstraction. Both don't seem too practical to me. To allow myself a final judgement, I must play around with it of course but I have the feeling, that managing interdependency wouldn't be that hard. Normally you would just use the trait. If you are brave and really know what you are doing, you can rename and excludes symbols. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: Traits for PHP
Hi Jochem, Am Mittwoch, den 20.02.2008, 01:20 +0100 schrieb Jochem Maas: [...] that sounds more than reasonable, but it might be worth offering an aid to developers during the compile time phase, with regard to the 'link' between a trait and an interface (assuming you would agree that it's not unlikely that the two would be used in tandem on occasion) without imposing/implying anything at run time (i.e. a trait may implement an interface to ensure correctness but that has no effect on any class that uses it, classes must explicitly state it's intention to implement an interface) I totally understand what you are trying to outline but I have the feeling that it would introduce a huge amount of complexity without adequate benefits. But that's of course just my opinion. cu, Lars -- Lars Strojny Senior Software Developer MediaVentures GmbH (http://mediaventures.de) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Error messages for wrong coding
2008/2/19, Cristian Rodriguez [EMAIL PROTECTED]: There is a similar case with unset() an offset of booleans and integers. ?php $foo = true: /* should throw a fatal error, like it does when trying to unset string offsets. actually $foo remains unchanged after unset() (!!) unset($foo[0]); Index: Zend/zend_vm_def.h === RCS file: /repository/ZendEngine2/zend_vm_def.h,v retrieving revision 1.59.2.29.2.48.2.36 diff -u -p -r1.59.2.29.2.48.2.36 zend_vm_def.h --- Zend/zend_vm_def.h 11 Feb 2008 15:46:10 - 1.59.2.29.2.48.2.36 +++ Zend/zend_vm_def.h 19 Feb 2008 14:32:18 - @@ -3281,6 +3281,7 @@ ZEND_VM_HANDLER(75, ZEND_UNSET_DIM, VAR| zend_error_noreturn(E_ERROR, Cannot unset string offsets); ZEND_VM_CONTINUE(); /* bailed out before */ default: + zend_error_noreturn(E_ERROR, Cannot unset %s offsets, zend_get_type_by_const(Z_TYPE_PP(container))); FREE_OP2(); break; } Added! I have updated the patch, because the bool variables (used internally on foreach, list(.., ..) = each(...), for example) are passed also to zend_fetch_dimension_address_read(), what break the previous patch (default: zend_error...) Then, i think that this could be handled in zend_vm_def.h, checking for OP1_TYPE != IS_VAR when the type is boolean. Well, i don't know how the Zend Engine works properly... So, If i said anything wrong, let me know, please. Finally, this was my suggestion. http://felipe.ath.cx/diff/bug39915.diff Thanks.
Re: [PHP-DEV] RFC: Traits for PHP
Lars Strojny schrieb: I think also for the sake of conceptual integrity separating interfaces clearly from traits is a good idea Interfaces are about (multiple) interface inheritance and traits are about (multiple) implementation inheritance. This separation of interface inheritance and implementation inheritance is ... awesome :) -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
