On 22.02.2008, at 18:20, Stanislav Malyshev wrote:
Hi!
A trait may contain methods and properties. When importing a trait
into a class, all methods and properties are imported in a way that
makes them only visible within the trait (I dont like the use of
"private"
How you are going to
On 22.02.2008, at 23:31, Gregory Beaver wrote:
I think you may be confused, because your statement about
refactoring is
inaccurate - for most methods, there would be no change from the
current
proposal. In other words, in my example above, you could use
trait1::a() simply as Blah::a, for i
Lukas Kahwe Smith wrote:
>
>> I have been uncomfortable with the current trait suggestions because
>> they occur in the body of the class, whereas extends/implements is
>> outside. I think there is a way to handle this, however.
>
> I dont agree here. traits are different. They do not affect "what
Richard Quadling schrieb:
On 21/02/2008, Richard Lynch <[EMAIL PROTECTED]> wrote:
In fact, new users are often confused because the CAN'T do an include
in the middle of a class -- A rule which, to some, seems arbitrary and
illogical.
And once they understand (if they do) why they cannot use
Hi!
Fun that you mentionned that structure greg because I was thinking of
something along those lines. Something very similar actually but the
aliasing could look like this:
trait One {
function name() { return __TRAIT__; }
function removeMe() {}
}
trait Two {
function name() { ret
Hi!
A trait may contain methods and properties. When importing a trait into
a class, all methods and properties are imported in a way that makes
them only visible within the trait (I dont like the use of "private"
How you are going to do that?
here .. its what confused me in the first propo
On Fri, Feb 22, 2008 at 11:21 AM, David Coallier <[EMAIL PROTECTED]> wrote:
>
> Well well well, sorry everyone. I'm just too cool to follow the rules
> :) Just kidding, I guess I will change email client and apply my
> signature to myself as well :)
I'm sure you will quote correctly next time..
Gregory Beaver schrieb:
Christian Schneider wrote:
Another detail: The implementation of the parser changes should still
allow a class or function called "trait", i.e. "trait" should only be a
keyword at specific positions in the source to avoid unneccesary BC
breaks. The current patch has this
On Fri, Feb 22, 2008 at 10:41 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> Let me briefly pick on poor David's (unfortunately I could have picked
> any number of posts on any given day just as well) recent emails [1]
> [2]: they are prima example of very bad quoting. Again I
Hi Lukas!
On Fri, Feb 22, 2008 at 4:41 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> Let me briefly pick on poor David's (unfortunately I could have picked
> any number of posts on any given day just as well) recent emails [1]
> [2]: they are prima example of very bad quotin
Hello all,
Let me briefly pick on poor David's (unfortunately I could have picked
any number of posts on any given day just as well) recent emails [1]
[2]: they are prima example of very bad quoting. Again I do not expect
everybody to read through the mailinglist README [3] from cover to
c
On Fri, Feb 22, 2008 at 10:32 AM, David Coallier <[EMAIL PROTECTED]> wrote:
>
> On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> >
> > On 22.02.2008, at 15:45, Gregory Beaver wrote:
> >
> > > Marcus Boerger wrote:
> > >> Hello Lukas,
> > >>
> > >> alrigh
On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>
> On 22.02.2008, at 15:45, Gregory Beaver wrote:
>
> > Marcus Boerger wrote:
> >> Hello Lukas,
> >>
> >> alright,
> >>
> >> 'foo as bar' is ok to me and does not even add a new keyword.
> >> Ignore or any mo
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should
re
Marcus Boerger wrote:
> Hello Lukas,
>
> alright,
>
>'foo as bar' is ok to me and does not even add a new keyword.
> Ignore or any more keywords are bad and I also think that the correct
> would be hide(ing). But as I further more explained it should really be
> something that only marks a
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should really be
something that only marks a method as private if at all. That can
On 21/02/2008, Stefan Marr <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Andi Gutmans schrieb:
> > a)
> > I think Traits should be able to act as a self-contained behavior which can
> > always be expected to work. For example if I want a Counter behavior
> I would like
> > that not to depend on the
On 21/02/2008, David Zülke <[EMAIL PROTECTED]> wrote:
> PHP needs to stop worrying about the "confusing newbies" thing when
> discussing advanced features. We're not talking about a basic bread
> and butter language construct here. Other parts of PHP aren't beginner
> friendly either, and not a
On 21/02/2008, Richard Lynch <[EMAIL PROTECTED]> wrote:
> I am not complaining.
>
> I think it's a FINE proposal.
>
> I'm suggesting an alternative solution which is simpler and easier to
> implement, with less confusion for new users.
>
> In fact, new users are often confused because the CAN'T
Stanislav Malyshev wrote:
Hi!
Just an uninformed thought: maybe the existing TSRM framework could
be leveraged to provide some simple multithreading support to the user.
TSRM is meant to support "share nothing" in threaded environment.
Multi-threading should support sharing data (including
20 matches
Mail list logo
