; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] RFC: Traits for PHP
On 21.02.2008, at 03:26, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can always be expected to work. For example if I want a
Counter behavior I would like that not to depend
Hello Lukas,
Thursday, February 21, 2008, 9:41:10 AM, you wrote:
On 21.02.2008, at 03:26, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can always be expected to work. For example if I want a
Counter behavior I would like that not to
Hi,
Marcus Boerger schrieb:
Trait a {
function f() {}
}
Trait b {
function f() {}
}
class c {
uses a, b;
function f() {}
}
Reflection(c):
function \0a\0f function a::f
function \0b\0f function b::f
function ffunction f
All nicely callable using array syntax:
class d
Hi!
The main part of the trait idea is to be able to solve conflicts
explicitly. Think this is the major contribution of traits and the
things being discussed here right now are not THIS kind of traits anymore.
What I still don't understand it's how you can solve these conflicts at
all.
Hi,
Stanislav Malyshev schrieb:
What I still don't understand it's how you can solve these conflicts at
all. I.e., suppose you have Counter API and DBConnection API on each of
which you have clean() method - for Counter it resets it to zero and for
DB it resets authentication details. How it
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Friday, February 22, 2008 9:21 AM
To: Lukas Kahwe Smith
Cc: Gregory Beaver; Marcus Boerger; [EMAIL PROTECTED]; Evert|Rooftop;
internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Traits for PHP
Hi
Gregory Beaver wrote:
So, as you can see, all of the trait methods are available as regular
methods except for A::a which is overridden by B::a. If the order were
reversed, i.e. traits B, A then $a-a() would instead call A::a.
I could see this becoming a problem when it plays along with
Hi,
Andi Gutmans schrieb:
I don't think so. I think the value here is not copypaste but to be
able to encapsulate some functionality which a class can be
decorated with. Giving a basic storage mechanism to that would be
very beneficial in a large amount of uses. Again, I am proposing
private
Hi,
The above presents a problem if trait2 contains conflicting method
names, but a simple way to solve it would be to automatically alias
methods by prepending traitname::
?php
trait trait1 { function a(){}}
trait trait2 { function a(){}}
class Blah extends ... implements ... traits trait1,
Hi,
Markus Fischer schrieb:
Hi,
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which
one?
think will work on the reflection part when details
On 21/02/2008, David Zülke [EMAIL PROTECTED] wrote:
PHP needs to stop worrying about the confusing newbies thing when
discussing advanced features. We're not talking about a basic bread
and butter language construct here. Other parts of PHP aren't beginner
friendly either, and not all
On 21/02/2008, Richard Lynch [EMAIL PROTECTED] wrote:
I am not complaining.
I think it's a FINE proposal.
I'm suggesting an alternative solution which is simpler and easier to
implement, with less confusion for new users.
In fact, new users are often confused because the CAN'T do an
On 21/02/2008, Stefan Marr [EMAIL PROTECTED] wrote:
Hi,
Andi Gutmans schrieb:
a)
I think Traits should be able to act as a self-contained behavior which can
always be expected to work. For example if I want a Counter behavior
I would like
that not to depend on the properties in
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should really be
something that only marks a method as private if at all. That can
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should really be
something that only marks a method
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should
On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and
On Fri, Feb 22, 2008 at 10:32 AM, David Coallier [EMAIL PROTECTED] wrote:
On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as
Hi!
A trait may contain methods and properties. When importing a trait into
a class, all methods and properties are imported in a way that makes
them only visible within the trait (I dont like the use of private
How you are going to do that?
here .. its what confused me in the first
Hi!
Fun that you mentionned that structure greg because I was thinking of
something along those lines. Something very similar actually but the
aliasing could look like this:
trait One {
function name() { return __TRAIT__; }
function removeMe() {}
}
trait Two {
function name() {
Richard Quadling schrieb:
On 21/02/2008, Richard Lynch [EMAIL PROTECTED] wrote:
In fact, new users are often confused because the CAN'T do an include
in the middle of a class -- A rule which, to some, seems arbitrary and
illogical.
And once they understand (if they do) why they cannot use
Lukas Kahwe Smith wrote:
I have been uncomfortable with the current trait suggestions because
they occur in the body of the class, whereas extends/implements is
outside. I think there is a way to handle this, however.
I dont agree here. traits are different. They do not affect what the
On 22.02.2008, at 23:31, Gregory Beaver wrote:
I think you may be confused, because your statement about
refactoring is
inaccurate - for most methods, there would be no change from the
current
proposal. In other words, in my example above, you could use
trait1::a() simply as Blah::a, for
On 22.02.2008, at 18:20, Stanislav Malyshev wrote:
Hi!
A trait may contain methods and properties. When importing a trait
into a class, all methods and properties are imported in a way that
makes them only visible within the trait (I dont like the use of
private
How you are going to
On 21.02.2008, at 03:26, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can always be expected to work. For example if I want a
Counter behavior I would like that not to depend on the properties
in the containing class. While I don't think
+1
Thanks for very detailed proposal.
I think Traits for PHP is good idea.
But I think, that use keword make some confusing, I propose have or
hold instead.
And ! not readable (imho) - I'd like not or except
And aliasing syntax (bar=foo) looks good in my mind.
--
PHP Internals - PHP Runtime
On 20/02/2008, Stefan Marr [EMAIL PROTECTED] wrote:
If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' = false
'trait_method' = 'new_name'
'trait_method' = array('new_name', 'trait_method'
I'm not comfortable with this notation, since it
Golemon; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] RFC: Traits for PHP
On 21.02.2008, at 03:26, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can always be expected to work. For example if I want a
Counter behavior I would like
On 21.02.2008, at 19:09, Andi Gutmans wrote:
I don't think so. I think the value here is not copypaste but to be
able to encapsulate some functionality which a class can be
decorated with. Giving a basic storage mechanism to that would be
very beneficial in a large amount of uses. Again,
PROTECTED]
Subject: Re: [PHP-DEV] RFC: Traits for PHP
On 21.02.2008, at 19:09, Andi Gutmans wrote:
I don't think so. I think the value here is not copypaste but to be
able to encapsulate some functionality which a class can be
decorated with. Giving a basic storage mechanism
about properties not methods. Please re-read it :)
Andi
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 10:51 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Traits for PHP
I am unclear on how this:
trait
On Mon, February 18, 2008 5:08 pm, David Coallier wrote:
On Feb 18, 2008 5:37 PM, Richard Lynch [EMAIL PROTECTED] wrote:
On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function
On Mon, February 18, 2008 7:45 pm, Rasmus Lerdorf wrote:
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
On Tue, February 19, 2008 8:29 am, Marcus Boerger wrote:
For that reason allowing traits in favor of include inside a class
body is
much better.
Once upon a time, there was a real difference between require and
include -- where require was compile-time and include was run-time.
PERHAPS it
Hi,
Andi Gutmans schrieb:
a)
I think Traits should be able to act as a self-contained behavior which can
always be expected to work. For example if I want a Counter behavior
I would like
that not to depend on the properties in the containing class. While I
don't
think we should enable
Hi,
Andi Gutmans schrieb:
I haven't thought this through completely but I think we may
want to consider a different model from supporting removing
and aliasing of functions. I think this can create a lot
of complications especially in larger works and it'll be
write-once code and hard for
Richard Lynch wrote:
On Mon, February 18, 2008 7:45 pm, Rasmus Lerdorf wrote:
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
Am 22.02.2008 um 00:16 schrieb Stefan Marr:
Sounds a bit like what had been proposed in this paper:
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca07b-FreezableTrait.pdf
The first point, yes exclusion and aliasing are only meant to handle
conflicts, and should be used only in this context.
Replies to a) and b) below:
Andi Gutmans wrote:
Hi Stefan,
Thanks for writing such a good proposal.
In general I think traits is a very interesting idea. I can think of a few
cases in my life as a programmer where it could have helped me out.
I think some comments re: the syntax/naming are
Hi Lars,
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
public function doSomething()
{
return str_replace(foo, bar, $this-_getString());
}
abstract protected _getString();
}
class
On 20.02.2008, at 09:28, Stefan Marr wrote:
Hi Lars,
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
public function doSomething()
{
return str_replace(foo, bar, $this-_getString());
}
abstract
Lars Strojny schrieb:
What about abstract methods in traits?
I do not think that this would make sense. Traits are about reusing
code. Abstract methods do not hold concrete code.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
Thank you for your attention and I'm looking forward to hear your comments
:)
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
Hi Lukas,
Am Mittwoch, den 20.02.2008, 09:44 +0100 schrieb Lukas Kahwe Smith:
[...]
Maybe its best to first leave out interfaces/abstract etc. Start
simple, see how things get used, get more comfortable with the feature
and then see about potentially expanding it.
I totally agree also I
Hi Derick,
1. can traits be put in a file of their own (I assume so actually)
2. can traits be autoloaded?
yes, since traits are zend_class_entrys with ce_flags set to
ZEND_ACC_TRAIT in the current implementation, they will follow the
same rules for definition and autoloading like classes.
On Mon, 18 Feb 2008, [EMAIL PROTECTED] wrote:
Thank you for your attention and I'm looking forward to hear your comments
And thank you for this very detailed proposal, I wish most other feature
proposals were like this. I like the concept, it seems to solve some
of the problems we had to hack
On 19 February 2008 21:03, [EMAIL PROTECTED] advised:
Hi Marcus,
Hi Troels,
The biggest issue I see is finding a syntax everyone likes.
Well, lets try some variations.
[2a] ! is not readable -- except
use Trait {
except foo1, foo2;
bar = foo1
}
[2b] ! is not readable --
Hi,
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which one?
lG
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi Markus,
Am Mittwoch, den 20.02.2008, 12:13 +0100 schrieb Markus Fischer:
[...]
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which one?
Markus Fischer wrote:
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which
one?
Dammit, sorry, I didn't intended to send it to all individuals.
On 20 Feb 2008, at 07:46, Sebastian Bergmann wrote:
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
Hello Stefan,
so at th eend of the day users will get renaming and will abuse it.
That said I am wondering if at the beginning we might want to do Traits
without aliasing and dropping. If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' = false
Hello Stanislav,
if we go the route of allowing that, then we have to do some protocl
checks. Meaning if a renamed/aliased method will become an implementation of
an abstract method then of course it has to be compatible. The beigger
problem I assume you have in mind as well is that replace
Hello Jochem,
good arguments. And good ideas. I'd favor 'posesses' then.
marcus
Tuesday, February 19, 2008, 9:54:09 PM, you wrote:
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
Hi!
Is there any reason why we cannot support multiple inheritance (which
Yes, there is. Ambiguity.
--
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
Hi Geoffrey,
Am Mittwoch, den 20.02.2008, 20:14 + schrieb Geoffrey Sneddon:
[...]
Is there any reason why we cannot support multiple inheritance (which
some other languages already do)? The only thing that needs to be
clearly defined is sorting order. This avoids trying to create some
If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' = false
'trait_method' = 'new_name'
'trait_method' = array('new_name', 'trait_method'
I'm not comfortable with this notation, since it strengthens the
impression that it is renaming.
In my eyes it
Marcus, Jochem,
Although I agree with the general idea, I feel strongly against
possesses, mainly because for a non-native english speaker it's a pita
to write and will (and I'm sure of this) *very* often be misspelled
(leading to general annoyances while debugging). I can't give any better
Hi Marcus,
Am Mittwoch, den 20.02.2008, 20:59 +0100 schrieb Marcus Boerger:
[...]
so at th eend of the day users will get renaming and will abuse it.
I disagree here. I think aliasing is fundamental to traits. If we think
of traits as buckets of functionality, the concrete structure of the
On Tue, Feb 19, 2008 at 3: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
a person coming accross 'use' or
Hi!
if we go the route of allowing that, then we have to do some protocl
checks. Meaning if a renamed/aliased method will become an implementation of
an abstract method then of course it has to be compatible. The beigger
I'm kind of confused on a use case for that. Suppose you have trait
On 20.02.2008, at 21:43, Stefan Marr wrote:
If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' = false
'trait_method' = 'new_name'
'trait_method' = array('new_name', 'trait_method'
I'm not comfortable with this notation, since it strengthens the
On 20 Feb 2008, at 20:28, Lars Strojny wrote:
Am Mittwoch, den 20.02.2008, 20:14 + schrieb Geoffrey Sneddon:
[...]
Is there any reason why we cannot support multiple inheritance (which
some other languages already do)? The only thing that needs to be
clearly defined is sorting order. This
John Campbell schreef:
On Tue, Feb 19, 2008 at 3: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
a person
Hi Stefan,
Thanks for writing such a good proposal.
In general I think traits is a very interesting idea. I can think of a few
cases in my life as a programmer where it could have helped me out.
I think some comments re: the syntax/naming are good ones but I prefer not to
get into naming in
On Wednesday 20 February 2008, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior which can
always be expected to work. For example if I want a Counter behavior I
would like that not to depend on the properties in the containing class.
While I don't
useful for Timers, Counters,
Containers, etc...
Andi
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 9:54 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Traits for PHP
On Wednesday 20 February 2008, Andi Gutmans wrote
My email talked about properties not methods. Please re-read it :)
Andi
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 10:51 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Traits for PHP
I am unclear on how
:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 9:54 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Traits for PHP
On Wednesday 20 February 2008, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can
always
[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
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
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
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() {
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
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
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
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
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
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
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
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
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
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
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,
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,
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
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
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
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
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
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
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,
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 -
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'
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
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``,
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 {
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
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.
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 {
1 - 100 of 122 matches
Mail list logo
