[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
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
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
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
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
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
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
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,
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
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
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
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
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
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.
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
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.
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 {
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?
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
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
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]);
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
54 matches
Mail list logo
