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
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 months
+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 - PHP Runtime
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
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 runtime
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 notation, since it
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
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
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
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; }} would
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 vs.
@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:
[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;
}
but
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 between
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'
Gregory Beaver wrote:
Here is a slightly clearer syntax for trait instantiation and for
aliasing/removing method names from traits:
?php
trait foo
...
class B
{
trait foo {unset bing, bar as bing};
trait bar;
}
I like the approach to reuse identifiers (trait both in
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)
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
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;
Sara
On 21.02.2008, at 19:09, Andi Gutmans wrote:
I don't think so. I think the value here is not copypaste 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,
-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; [EMAIL
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.
/de-lurk
--Larry Garfield
On Wed, 20 Feb 2008 23:19:23 -0800, Andi Gutmans [EMAIL PROTECTED] wrote:
My email talked
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:
?php
trait ezcReflectionReturnInfo {
function getReturnType() { /*1*/ }
function
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 this
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
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:
Hi,
what's about sample below?
?php
class foo
{
public $aabb;
const bbaa = 'abba';
static public $baba;
function bar(){}
function bing(){}
}
class bar
{
const baab = foo::bbaa;
function bar(){}
}
class A
{
trait foo;
}
class B
{
trait foo {unset bing, bar as
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
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 problems
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 hard for
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
lot
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
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,
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
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
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
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
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
[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
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 b);
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 BC
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
42 matches
Mail list logo
