Hi!
Just had a look over the RFC, and from what I gathered was that only the
issue of aliasing/renaming seems slightly controversional. Would it be
possible to commit traits without this feature for now?
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi!
Just had a look over the RFC, and from what I gathered was that only the
issue of aliasing/renaming seems slightly controversional. Would it be
possible to commit traits without this feature for now?
Stefan recently got karma and told me he can commit his traits patch after the 15th.
I do not really think we should leave out the aliasing, lets have as many people as possible play with it as is. We can always tweak/change/drop it later.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
Just had a look over the RFC, and from what I gathered was that only the
issue of aliasing/renaming seems slightly controversional. Would it be
possible to commit traits without this feature for now?
Stefan recently got karma and told me he can commit his traits patch after the 15th.
I do not really think we should leave out the aliasing, lets have as many people as possible play with it as is. We can always tweak/change/drop it later.
Right, I am hunting an important deadline at the moment, so was going to split up the changes afterwards in step-wise patches, to make things easier digestible.
But just as a quick response, without aliasing, there would be no way to use a conflicting method from a trait.
On first sight, that is not a really good thing.
Best regards
Stefan
Hi!
But just as a quick response, without aliasing, there would be no way
to use a conflicting method from a trait.
On first sight, that is not a really good thing.
Hi Stefan, is it possible to have renaming and aliasing?
Some context, say we have:
trait Something {
function renameIssue() {
$method = 'call';
$this->$method();
call_user_func(array($this, $method));
}
function call () {
echo "a";
}
}
class Foo {
use Something {
function call() as call2();
}
}
With renaming:
$f = new Foo;
$f->call2(); // a
$f->renameIssue(); // call() method does not exist
With aliasing:
$f = new Foo;
$f->call(); // a
$f->call2(); // a
$f->renameIssue(); // a
While aliasing prevents the error, the syntax could re-use the 'clone'
keyword:
class Foo {
use Something {
function call() clone call2();
}
}
So we'd have both behaviors:
class Foo {
use Something {
function call() as call2();
function call() clone call3();
}
}
We have call(), call2(), call3()
class Foo {
use Something {
function call() as call2();
}
}
We have call2()
Other than that, the traits proposal still feels incomplete compared to
grafts since from Stefan's research: "the lack of state means that virtually
all traits are incomplete"
It's still a great step if the current proposal (methods only) gets
committed.
Hi!
But just as a quick response, without aliasing, there would be no way
to use a conflicting method from a trait.
On first sight, that is not a really good thing.Hi Stefan, is it possible to have renaming and aliasing?
Some context, say we have:
trait Something {
function renameIssue() {
$method = 'call';
$this->$method();
call_user_func(array($this, $method));
}
function call () { echo "a"; }
function invokeCallDirectly() { $this->call(); }
}class Foo {
use Something {
function call() as call2();
}
}With renaming:
$f = new Foo;
$f->call2(); // a
$f->renameIssue(); // call() method does not exist
I have added invokeCallDirectly() to your example. What should be the semantics of that? Should that call be refitted to invoke call2?
Am not sure that this is a good idea, with all this other ways around to call methods dynamically. Ok, aliasing is 'kind of annoying' and unusual but from my perspective not much different then what we do with variables every day. They reference objects, and we introduce new aliases for old objects every now and then.
the syntax could re-use the 'clone' keyword:
class Foo {
use Something {
function call() clone call2();
}
}
Would be an option, but it reads kind of strange, doesn't it?
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525