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
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 all
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 do an
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 properties in
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
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 method
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
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 more keywords are bad and
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,
alright,
'foo as
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
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 quoting.
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 do
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 BC
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..
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
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() {
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
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 the
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
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
20 matches
Mail list logo
