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();
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
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) { ... }
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
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
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
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?
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);
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 -
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 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
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
On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
}
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
So it's just like
Fantastic. Nice RFC, nice explanation, nice design - I love it.
Can I
+1
already? :)
David
Am 18.02.2008 um 20:27 schrieb [EMAIL PROTECTED] [EMAIL PROTECTED]
marr.de:
Hi,
during last six months I've studied a language construct called
Traits.
It is a construct to allow
So it's just like an include for a re-used body of 'class' code.
H.
Why not just allow 'include' here instead?
Well, think this would be a Mixin mechanism like in Ruby.
Forgive me if I'm missing something subtle/complex here, but I wonder
if a Trait is really the right answer...
Yes,
Hi David,
On Feb 19, 2008 12:08 AM, David Coallier [EMAIL PROTECTED] wrote:
Read the proposal, read about traits, read the thesis, read the patch,
then if you still don't understand, give up, and if you do understand,
you can complain.
If you don't understand, ask. If you still don't
On Monday 18 February 2008, Richard Lynch wrote:
On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function getReturnDescription() { /*2*/ }
}
class ezcReflectionMethod extends
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
On Monday 18 February 2008, Rasmus Lerdorf 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. :-)
[EMAIL PROTECTED] schrieb:
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.
Thank you, Stefan, for your thorough RFC.
A patch implementing this new language construct is available, too.
I tested an
Rasmus Lerdorf schrieb:
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.
Thanks to their Flattening Property, there should be no notion
Rasmus Lerdorf schrieb:
This was in response to the suggestion that it should be extended to do
runtime conditional modification of the classes.
Ah, sorry.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
101 - 122 of 122 matches
Mail list logo
