http://wiki.php.net/rfc/traitsmodifications
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like 'final'
could also do something special.
André
That might seem odd but it's not inheritance.
Yeah. And that's my main concern with it. It seems like inheritance (and
is described like inheritance in the RFC at present--which is a
documentation issue that will need to be addressed in the manual
eventually), but it isn't. I feel it should be o
On 13/02/11 9:15 PM, André Rømcke wrote:
On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt
wrote:
On 11/02/11 3:37 AM, Philip Olson wrote:
You now have rights to the wiki rfc namespace.
Thanks a lot, Philip.
I have now made an RFC based on the most recent discussions:
http://wiki.php.net/rfc/
On Thu Feb 10 12:25 PM, Ben Schmidt wrote:
>
> http://wiki.php.net/rfc/traitsmodifications
>
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like '
On Sun Feb 13 05:15 AM, André Rømcke wrote:
> >
> > I have now made an RFC based on the most recent discussions:
> >
> > http://wiki.php.net/rfc/traitsmodifications
> >
>
> I think it would sometimes be desirable to allow this, for instance
> when a trait has been updated in a framework to adapt
On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt
wrote:
> On 11/02/11 3:37 AM, Philip Olson wrote:
>
>> You now have rights to the wiki rfc namespace.
>>
>
> Thanks a lot, Philip.
>
> I have now made an RFC based on the most recent discussions:
>
> http://wiki.php.net/rfc/traitsmodifications
>
> I thi
On 11/02/11 3:37 AM, Philip Olson wrote:
You now have rights to the wiki rfc namespace.
Thanks a lot, Philip.
I have now made an RFC based on the most recent discussions:
http://wiki.php.net/rfc/traitsmodifications
I think this is a more solid proposal than my original one, and I hope
we can
On Feb 9, 2011, at 9:55 PM, Ben Schmidt wrote:
>> - Don't write long e-mails to a mailing list, write an RFC
>> http://wiki.php.net/rfc?do=register
>
> OK. I tried to do this. I got an account (username:isfs), but it seems
> it is nothing more than an unprivileged account--I don't seem to be abl
- Don't write long e-mails to a mailing list, write an RFC
http://wiki.php.net/rfc?do=register
OK. I tried to do this. I got an account (username:isfs), but it seems
it is nothing more than an unprivileged account--I don't seem to be able
to edit or add pages at all. What do I need to do to be g
On Sat Jan 8 06:33 AM, Ben Schmidt wrote:
>
> > Creating a patch will help getting feedback about what you're
> > proposing http://ca3.php.net/reST/php-src/README.MAILINGLIST_RULES
>
> I hope I haven't broken any of the mailing list rules, but my
> apologies if I have, and please point out spec
In fact, this is so nice, could I suggest it would be nice to allow
other delegation-like forwarding to be done like this? You could have
'use' without a trait even, just like this:
use {
$queue->add as addToQueue;
}
Since the properties' object wouldn't be available at compile time, this
ext
Hi, Stefan,
I think if the other stuff goes ahead, we can probably scrap what I
originally proposed here. But perhaps something else would be helpful. I
won't comment very specifically on aspects of my original proposal, but
will just raise some new ideas for consideration and further thought.
I
Hi again, Stefan,
Continuing the conversation.
On 7/01/11 10:18 AM, Stefan Marr wrote:
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
Extension
- - - - -
I suggest these two problems can be simply solved by introducing two
additional uses of the trait keyword: as a scoping keyword and an access
Hi, Stefan,
Thanks for considering my ideas so carefully and for your detailed
replies.
The reason to go with insteadof is that the assignment syntax hides
changes that might cause problems.
Thus, when you change any of the traits participating in a composition
in a way that a conflict would b
Hi, Jonathan,
On 7/01/11 4:42 AM, Jonathan Bond-Caron wrote:
- New ideas are always welcome
That's great to hear!
- Don't write long e-mails to a mailing list, write an RFC
http://wiki.php.net/rfc?do=register
Sure. Once I've digested and responded to Stefan's replies, I'll work on
putting
Hi Ben:
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
> Proposal
>
>
> I would therefore like to propose an extension backwards-compatible with
> the current trait implementation. I will, however, extend the assignment
> syntax, rather than the 'insteadof' syntax, as I find that clearer,
Hi Ben:
Here the second part, on your extension proposal.
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
> Extension
> - - - - -
>
> I suggest these two problems can be simply solved by introducing two
> additional uses of the trait keyword: as a scoping keyword and an access
> specifier.
>
> As
Hi Ben:
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
> While it's still in the pre-release stage, though, I would like to put
> in a vote for the assignment syntax: I think it is a lot easier to read
> and understand than the 'insteadof' syntax.
The reason to go with insteadof is that the assignm
On Sun Jan 2 07:16 AM, Ben Schmidt wrote:
> I would also like to propose some extensions to the functionality as
> currently described, which I think could potentially add tremendous
> power to the mechanism, with relatively little additional conceptual
> complexity and implementation effort. I'
Hello, PHP developers,
I'm new to the list, but have been using PHP for a number of years, have
done a little hacking in the source code, and have an interest in the
development of the language.
Particularly recently I have been reading with a good deal of excitement
Stefan Marr's RFC on 'horizo
20 matches
Mail list logo
