On 22.02.2008, at 06:56, Gregory Beaver 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
Hi,
>well, there is http://pecl.php.net/package/threads
>it was never finished, thogh
After I played around with this extension, I've finally compiled a working
version for included files (thread_include(...)) which also doesn't crash any
more
at shutdown (WinXP, PHP 5.2.2).
This extension nee
Christian Schneider wrote:
> So my favourite solution (apart from allowing include in class
> definitions ;-)) would be
> trait foo { ... }
> ...
> class B
> {
> trait foo; # All functions from foo
> trait bar(a); # Only function a from bar
> trait qux(not
[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 with the questions what Traits
Replies to a) and b) below:
Andi Gutmans wrote:
Hi Stefan,
Thanks for writing such a good proposal.
In general I think traits is a very interesting idea. I can think of a few
cases in my life as a programmer where it could have helped me out.
I think some comments re: the syntax/naming are go
Stefan Marr wrote:
Hi,
D. Dante Lorenso schrieb:
All,
I can imagine a case where you would want to box common functionality
into a trait and be able to use that trait as a class also. Will we
end up with a lot of classes like this?:
class SomeClass {
use SomeTrait;
}
What's wrong with
I hate to piss on anybody's bonfire, but...
I'm not, never was, an OO fan. OO is one of those things I'm more and more
forced to deal with... even in C coding (wtf is that all about?). It's OK, I
won't create this OO stuff but I can deal with it when I see it... nowadays.
But I also remember a
Hi,
D. Dante Lorenso schrieb:
All,
I can imagine a case where you would want to box common functionality
into a trait and be able to use that trait as a class also. Will we end
up with a lot of classes like this?:
class SomeClass {
use SomeTrait;
}
What's wrong with making all 'Class'es
All,
I can imagine a case where you would want to box common functionality
into a trait and be able to use that trait as a class also. Will we end
up with a lot of classes like this?:
class SomeClass {
use SomeTrait;
}
What's wrong with making all 'Class'es be 'Trait's and the only thing
Hi,
jvlad schrieb:
Why would this create any problems? Say, you have class B that extends class
A and both do define one method and one property under the same names. Will
this create a problem? No. It's because there are rules that clearly
describe how it works (method and property will be ov
Am 22.02.2008 um 00:16 schrieb Stefan Marr:
Sounds a bit like what had been proposed in this paper:
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca07b-FreezableTrait.pdf
The first point, yes exclusion and aliasing are only meant to handle
conflicts, and should be used only in this context.
Hi,
Andi Gutmans schrieb:
I haven't thought this through completely but I think we may
> want to consider a different model from supporting "removing"
> and "aliasing" of functions. I think this can create a lot
> of complications especially in larger works and it'll be
> write-once code and ha
"Stefan Marr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> jvlad schrieb:
>> in other words, why to introduce such a new thing as trait instead of
>> using classes and trait'ing them?
> I've introduced it as a separate notion from classes to avoid
> misconception and pr
Richard Lynch wrote:
> On Mon, February 18, 2008 7:45 pm, Rasmus Lerdorf wrote:
>> The idea here is that we want to be able to cache opcodes, classes and
>> functions and optimize them out of the runtime context so the executor
>> can skip creating classes and functions on every single request. A
Hi,
jvlad schrieb:
in other words, why to introduce such a new thing as trait instead of using
classes and trait'ing them?
I've introduced it as a separate notion from classes to avoid
misconception and problems occurring from conflicting properties and
constant definitions.
Your example dem
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 the containing class. While I
don't
> think we should enable p
Hi,
what's about sample below?
in other words, why to introduce such a new thing as trait instead of using
classes and trait'ing them?
just my two cents.
-j
"Gregory Beaver" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> Here is a slightly clearer syntax for trait in
Hi,
have updated the RFC and added several syntax proposals.
Additionally I've ported the patch to PHP_5_3
(http://toolslave.net/snapshots/traits/traits-5.3.patch).
Kind Regards
Stefan
:Version: 1.2
:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
:TXT: http://www.stefan-ma
On Tue, February 19, 2008 8:29 am, Marcus Boerger wrote:
> For that reason allowing traits in favor of include inside a class
> body is
> much better.
Once upon a time, there was a real difference between require and
include -- where require was compile-time and include was run-time.
PERHAPS it
On Mon, February 18, 2008 7:45 pm, Rasmus Lerdorf wrote:
> The idea here is that we want to be able to cache opcodes, classes and
> functions and optimize them out of the runtime context so the executor
> can skip creating classes and functions on every single request. A
> lot
> of the traffic on
On Mon, February 18, 2008 5:08 pm, David Coallier wrote:
> On Feb 18, 2008 5:37 PM, Richard Lynch <[EMAIL PROTECTED]> wrote:
>> On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
>> > > > trait ezcReflectionReturnInfo {
>> >function getReturnType() { /*1*/ }
>> >function getRetur
Ah, I thought you were talking about both. Non-public makes more sense for
properties, but I thought you were talking about methods not having ppp either.
No worries then.
--Larry Garfield
On Wed, 20 Feb 2008 23:19:23 -0800, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> My email talked about
> -Original Message-
> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 21, 2008 10:32 AM
> To: Andi Gutmans
> Cc: [EMAIL PROTECTED]; internals@lists.php.net; Marcus Börger;
> Johannes Schlüter; Sebastian Bergmann; Alexandre Bergel; Falko Menge;
> Sara Golemon;
On 21.02.2008, at 19:09, Andi Gutmans wrote:
I don't think so. I think the value here is not copy&paste but to be
able to encapsulate some functionality which a class can be
decorated with. Giving a basic storage mechanism to that would be
very beneficial in a large amount of uses. Again,
See below:
> -Original Message-
> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 21, 2008 12:41 AM
> To: Andi Gutmans
> Cc: [EMAIL PROTECTED]; internals@lists.php.net; Marcus Börger;
> Johannes Schlüter; Sebastian Bergmann; Alexandre Bergel; Falko Menge;
> Sar
Hi!
I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
Multithreading does not fit well in the set of assumptions PHP engine is
built on (thoug
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 locking &
synchronization)
Gregory Beaver wrote:
> Here is a slightly clearer syntax for trait instantiation and for
> aliasing/removing method names from traits:
>
> trait foo
...
>
> class B
> {
> trait foo {unset bing, bar as bing};
> trait bar;
> }
I like the approach to reuse identifiers (trait both in dec
Hello,
What about has?
interface context {
/* ... */
}
trait contextA implements context {
/* ... */
}
class A {
has contextA;
has foobar;
}
In my opinion it is similar and descriptive like you having to implement an
interface with implements, extend a class with 'extends' and
On 2/21/08, Nathan Rixham <[EMAIL PROTECTED]> wrote:
> Thankyou for taking the time to shed some light on the mater for me; I'd
> missed the all vital "sharing resources" part of the concept, probably
> because (if I'm correct in saying) php shares memory of
> variables/classes/resources betwee
[snip...]
>
> class A
> {
> trait foo;
> }
>
> class B
> {
> trait foo {unset bing, bar as bing};
> trait bar;
> }
> ?>
>
[snip...]
As long as we're discussing syntax - I rather like
class A
{
attach foo;
}
class B
{
attach foo {hide bing, bar as bing};
attach bar
@Stefan: are you keeping track of all the different syntax proposals?
Yes, I try to keep step with all those different proposals and sum them
up in the end of the day.
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
Hi,
Am Donnerstag, den 21.02.2008, 13:55 +0100 schrieb Lukas Kahwe Smith:
[...]
> I like "trait" instead of "use" or any of the other proposals as well
Do you like "class Foo class Bar" instead of "class Foo extends Bar"?
Normally PHP uses a descriptive naming scheme, while "class Foo { trait
XY;
On 21.02.2008, at 07:55, Gregory Beaver wrote:
Simply re-using "trait" instead of "use" is a more self-documenting
solution. I found it slightly confusing to see "use" when that is a
namespace-specific token currently. This is also in keeping with the
way functions are defined in interfaces v
www.halo3-tournaments.com
4v4 tournaments coming up on March 1st
$40/team entry
$500 prize
2v2 tournaments coming up on March 15th
$20/team entry
$300 prize
Chance for sponsorship will be available for those teams who are looking to go
professional in gaming industry
visit us at www.halo3-tou
Alexey Zakhlestin wrote:
On 2/21/08, Nathan Rixham <[EMAIL PROTECTED]> wrote:
hope you don't mind me asking for a bit more info, I was always under
the impressions that a thread is defined as (quote wiki)
"Threads are a way for a program to fork (or split) itself into two or
more simultaneou
On 21.02.2008 01:08, Sebastian wrote:
> hi,
>
> why isn't it possible to assign class constants like this:
>
> class test
> {
>const
> DIR='dirname'.DIRECTORY_SEPARATOR.'anotherdirname'.DIRECTORY_SEPARATOR;
> }
Because concatenating is an expression, expressions are executed in runt
On 20/02/2008, Stefan Marr <[EMAIL PROTECTED]> wrote:
> > If we feel it gets necessary we probbaly
> > might want to support a syntax like:
> > 'trait_method' => false
> > 'trait_method' => 'new_name'
> > 'trait_method' => array('new_name', 'trait_method'
>
> I'm not comfortable with this no
On 2/21/08, Nathan Rixham <[EMAIL PROTECTED]> wrote:
> hope you don't mind me asking for a bit more info, I was always under
> the impressions that a thread is defined as (quote wiki)
>
> "Threads are a way for a program to fork (or split) itself into two or
> more simultaneously (or pseudo-simu
David Coallier wrote:
On Wed, Feb 20, 2008 at 10:36 PM, Felipe Ribeiro <[EMAIL PROTECTED]> wrote:
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.
My question is if
+1
Thanks for very detailed proposal.
I think "Traits for PHP" is good idea.
But I think, that "use" keword make some confusing, I propose "have" or
"hold" instead.
And "!" not readable (imho) - I'd like "not" or "except"
And aliasing syntax (bar=>foo) looks good in my mind.
--
PHP Internals -
well, there is http://pecl.php.net/package/threads
it was never finished, thogh
Here's the thread about it, from last august:
http://thread.gmane.org/gmane.comp.php.pecl.devel/3996
On 2/21/08, Felipe Ribeiro <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've been reading this list for a couple of mont
On 21.02.2008, at 03:26, Andi Gutmans wrote:
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 the containing class. While I don't think w
43 matches
Mail list logo
