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
2008/2/19, Cristian Rodriguez <[EMAIL PROTECTED]>:
>
> There is a similar case with unset() an offset of booleans and integers.
>
> $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]
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
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 t
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
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 wa
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 wa
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
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 messa
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
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 suc
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
if
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
st
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 cl
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 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 fo
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.
http://www.cristianrodriguez.net
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 message as soon as class is found
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 mor
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
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
> cou
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
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-lev
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"; }
fu
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 a
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]"
An with CGI module, we already have the username.
It should be enough t
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:
>
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
[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 co
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 followi
57 matches
Mail list logo
