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 i
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. I.e.
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 "f"function f
All nicely callable using array syntax:
class d
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 n
Bergmann; Alexandre Bergel; Falko Menge;
>> Sara 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-conta
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 o
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::
would create method "trait2::a" and we can alias it in the class body.
Also, $a->{'trait2::a'}(); is legal syntax, so n
Hi,
Andi Gutmans schrieb:
I don't think so. I think the value here is not copy&paste 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 st
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 n
> -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: T
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 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 i
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
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
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() { ret
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 propo
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,
> > >>
> > >> alrigh
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 mo
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
re
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
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
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
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 a
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
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 go
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.
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 ha
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
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 p
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
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
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:
>> > > > trait ezcReflectionReturnInfo {
>> >function getReturnType() { /*1*/ }
>> >function getRetur
gt; 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: [PH
ge;
> Sara Golemon; [EMAIL 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 copy&paste but to be
> > able to encapsulate some functionality which
On 21.02.2008, at 19:09, Andi Gutmans wrote:
I don't think so. I think the value here is not copy&paste 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,
ergel; Falko Menge;
> Sara 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 t
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 no
+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 -
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 w
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
>
>
> -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 wro
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 Februa
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
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 thi
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 co
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
imp
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
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
f
> 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
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 som
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 unsubsc
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 '
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 TFo
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
tr
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 inheritan
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 migh
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:
>> Hell
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
'trai
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.
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, visit:
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 rea
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.
Ki
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 Mon, 18 Feb 2008, Richard Lynch wrote:
> On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
> > > trait ezcReflectionReturnInfo {
> >function getReturnType() { /*1*/ }
> >function getReturnDescription() { /*2*/ }
> > }
> >
> > class ezcReflectionMethod extends ReflectionMe
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
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());
}
abstra
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();
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 09
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 {
publ
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 impl
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
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
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 - i
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?
Ye
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
thi
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 PROTECTE
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($ke
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 sho
On Feb 19, 2008 11:45 PM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> 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
>
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::
trait SayHello implements IHello {
public function sayHello() {
echo 'He
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::
> >
> > > interface IHello {
> >public function s
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) { ... }
func
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::
>
>interface IHello {
>public function sayHello();
> }
>
> trait SayHello implements IHello {
>
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';}
}
trai
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``
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 n
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 (t
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(
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 del
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=>
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 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=
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 f
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
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
>
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 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 tra
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
1 - 100 of 128 matches
Mail list logo
