So it's just like an include for a re-used body of 'class' code.
H.
Why not just allow 'include' here instead?
Well, think this would be a Mixin mechanism like in Ruby.
Forgive me if I'm missing something subtle/complex here, but I wonder
if a Trait is really the right answer...
Yes,
Hi Mark,
If it doesn't affect performance *MUCH* then I'm all for it ! It can
bring better structure for complex designs. Also by reusing, I'm
assuming less memory will be needed for the code base which is beneficial.
the current implementation does not save any memory compared to a
user-level
Hi Larry,
It sounds interesting to me, and I can definitely see the value. I think I'd
suggest having multiple included traits override each other, however, so
that:
trait A {
function foo() { echo A; }
function bar() { echo A; }
}
trait B {
function foo() { echo B; }
function bar() {
Hi Richard,
A question (and again, no idea on feasibility, internals, etc.).
The above proposal covers adding/overriding internal methods with
external ones. Is it possible to also include additional properties?
If not, then you would have to override the constructor method (this
could be
Hi Marcus,
Hi Troels,
The biggest issue I see is finding a syntax everyone likes.
Well, lets try some variations.
Since renaming happens in a php array like
style I would prefer to have that approach apply for ignoring methods as
well. The way to do that imo is 'method=false' or
Hi Stanislav,
traits the included trait is using). Ok this is the scope. Now we
would need to adjust all those method bodies, find all method calls on
$this-oldMethodName() and change them to $this-newMethodName().
You can't - PHP has dynamic method resolution (think $this-$foo()).
Also,
Personally I like everything but one tiny piece, that is you do '!method'
to ignore a method from a trait. Since renaming happens in a php array like
style I would prefer to have that approach apply for ignoring methods as
well. The way to do that imo is 'method=false' or 'method=NULL'
Hi Evert,
Aliasing doesn't make a lot of sense, as you can always :
function newMethod() {
return $this-oldMethod();
}
Don't think so.
You do use aliasing to handle conflicts and in the case of a conflict
there is no oldMethod.
trait A {
public function foo() {echo 'foo';}
}
trait B {
Hi Larry,
So if the Trait is not stateful, what is the advantage over delegation? That
was cited in an earlier email as a shortcoming of delegation, but if the
Traits
implementation doesn't address it either except through a getter/setter, then
it's still functionally equivalent to
2008/2/19, Lars Strojny [EMAIL PROTECTED]:
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::
?php
interface IHello {
public function sayHello();
Hi Lars,
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
public function doSomething()
{
return str_replace(foo, bar, $this-_getString());
}
abstract protected _getString();
}
class
Hi Derick,
1. can traits be put in a file of their own (I assume so actually)
2. can traits be autoloaded?
yes, since traits are zend_class_entrys with ce_flags set to
ZEND_ACC_TRAIT in the current implementation, they will follow the
same rules for definition and autoloading like classes.
Hi,
I've updated the RFC on several sections to reflect the discussion on this list.
The following parts have been changed or added:
- introduced explicit description of abstract methods to be used as
requirements
specification for traits (useful to access state)
- moved part about
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 strengthens the
impression that it is renaming.
In my eyes it
@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:
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,
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
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
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
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
Hi,
I came across one piece of information on aliasing that may not be
obvious at first and therefore should probably be explicitly stated in
the RFC and in the manual when this makes it into the core.
Quoting http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf:
Note that because
Hi,
Andi Gutmans schrieb:
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, I am proposing
private
Hi,
The above presents a problem if trait2 contains conflicting method
names, but a simple way to solve it would be to automatically alias
methods by prepending traitname::
?php
trait trait1 { function a(){}}
trait trait2 { function a(){}}
class Blah extends ... implements ... traits trait1,
Hi,
Steph Fox schrieb:
All I'm seeing here is people with CS degrees saying trait would be
cool. What about us peasants? Or am I the last living peasant? :\
That's possible, I suppose.
Sell it to me?
A very cool thing of traits is the flattening property ensuring that
there is no
Hi,
Christian Schneider schrieb:
I can see two
use cases for aliasing:
1) An interface uses a different name than the
trait implements. Not sure that's a software design problem trait should
try to solve.
Well, no, aliasing shouldn't be used to achieve this, think it would be
better to add
Hi,
Markus Fischer schrieb:
Hi,
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which
one?
think will work on the reflection part when details
Hi,
Marcus Boerger schrieb:
Trait a {
function f() {}
}
Trait b {
function f() {}
}
class c {
uses a, b;
function f() {}
}
Reflection(c):
function \0a\0f function a::f
function \0b\0f function b::f
function ffunction f
All nicely callable using array syntax:
class d
Hi Michael,
Michael Stack schrieb:
Apologies for contacting you off list. I would like it if you would
consider the following additional alternative syntax for aliases.
has foo {
without bar, gaa; // exclusions
with zaa as zee, faa as fee; // with aliased methods
}
After you had posted
Pierre Joye schrieb:
Limiting the RFC to existing php.net's member sound like a bad idea
and create CVS accounts only for a RFC does not sound any better.
I would rather use the wiki for the complete process. Once a RFC
reached a stable status, we can add it to a RFC repository.
Would agree
Hi,
there is a lot of discussion going on about how traits should actually
work in PHP.
Currently, one of the main challenges seams to be to agree on a suitable
mechanism to avoid breaking traits and there behavior.
Eventually, there seams to be a large discomfiture on the excluding of
methods
Hi,
Stanislav Malyshev schrieb:
What I still don't understand it's how you can solve these conflicts at
all. I.e., suppose you have Counter API and DBConnection API on each of
which you have clean() method - for Counter it resets it to zero and for
DB it resets authentication details. How it
Hi Joshua,
Joshua Thompson schrieb:
trait A {
public function smallTalk() {
return 'a';
}
public function bigTalk() {
return strtoupper( $this-smallTalk() );
}
}
trait B {
public function smallTalk() {
return 'b';
}
public function bigTalk() {
return strtoupper(
Hi Richard,
Richard Quadling schrieb:
Traits as namespaces would solve the issue of conflict in the class
Talker (you would have to explicitly say which trait the method came
from.
Yes, this would solve the conflicts, but is this really handy?
Every explicit reference to a trait/class name has
Lukas Kahwe Smith schrieb:
class Talker {
use A, B, C, D {
smallTalk = A::smallTalk; // this says that if B, C or D implement
smallTalk, it is ignored
talk = A::bigTalk;
}
}
Well this is not just a different syntax, but an entirely different
approach. In Stefan's proposal one had to
Hi,
Joshua Thompson schrieb:
Andi Gutmans wrote:
The following code shows a few things:
- local properties which can be used in self-contained functionality.
The storage is guaranteed to stay internal and will not clash with the
aggregating class.
Yes, it is a nice to have.
- methods are by
Hi Joshua,
seams to me the interest in traits decreases rapidly :(
Joshua Thompson schrieb:
trait A1 {
private $a = 'A1';
private function printA() {
echo $this-a;
}
public function callPrintA1() {
$this-printA();
}
}
trait A2 {
private $a = 'A2';
Hi Joshua,
have added your RFC to the wiki.
(http://wiki.php.net/rfc/nonbreakabletraits)
Hope it is ok for you.
Think we should somehow summarize the pro and cons for our proposals.
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
-for-php.html
:TXT: http://www.stefan-marr.de/rfc-horizontal-reuse-for-php.txt
:Author: Stefan Marr php.at.stefan-marr.de
:Previous RFC: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
:Related RFC: http://wiki.php.net/rfc/nonbreakabletraits
.. contents::
This RFC will discuss two different
Hi,
Christopher Vogt schrieb:
Hej everybody,
I really liked to see the Grafts proposal.
Well, I'm still in love with the more powerful (because they are
interweaveable(breakable)) Traits ;)
The Grafts proposal, however, suffered a little from being born out of
traits, I think. Something
Hi,
On 25 Nov 2008, at 13:39, Marcus Boerger wrote:
Your points are all well observed. And yes I limit what my approach
can
do in order to Keep It Simple Safe (KISS). While still being able to
manually interfere with/overload the autogenerated code when
necessary.
At the same time
Hello internals,
the traits are back and up to date with the RFC.
Since there was not much discussion about the grafts idea, I
implemented a new patch to give you the opportunity to test the
proposed Traits on your own.
I have attached a patch for HEAD and an archive with test cases which
Description: BZip2 compressed data
On 15 Jan 2009, at 17:21, Stefan Marr wrote:
Hello internals,
the traits are back and up to date with the RFC.
Since there was not much discussion about the grafts idea, I
implemented a new patch to give you the opportunity to test the
proposed Traits
Hi,
just a suggestion, have you thought about using Quercus [http://www.caucho.com/resin-3.0/quercus/
]
or Project Zero [http://www.projectzero.org/download/]?
This projects are implementing PHP in Java.
Regards
Stefan
On 05 Feb 2009, at 16:12, Terry Braun wrote:
Hello,
I've written a
] http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07eStatefulTraits.pdf
--
Stefan Marr
Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
, so this could of course be
specified different.
Best regards
Stefan
--
Stefan Marr
Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
proposal, if we do not forbid
any access to properties inside of trait methods (which sounds like a
stupid idea to me). :(
Regards
Stefan
Feedback?
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stefan
Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stefan Marr
Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
--
PHP Internals - PHP Runtime Development Mailing List
syntax
tree instead of a instruction set like Java
bytecode. Thats not a technical problem, but merely
an academic question to categorize/characterize PHP.
All comments are welcome.
Many thanks
Stefan
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit
Hi Paul:
To start with, the best reference about the Zend engine that I know of
is a presentation by Andy Wharmby at IBM:
www.zapt.info/PHPOpcodes_Sep2008.odp. It should answer a lot of your
questions.
Thanks a lot, was not aware of that one. And, well it helps to read
and understand
the
On 16 Aug 2009, at 19:56, Lothar Scholz wrote:
Hello Sebastian,
Monday, August 17, 2009, 12:38:59 AM, you wrote:
SB Paul Biggar schrieb:
There was a POPL paper this year on Copy-on-write in PHP
SB http://doi.acm.org/10.1145/1480881.1480908
I think they are pulled out of thin air. More specifically, I think
there are optimizations heaped upon optimizations heaped upon an
initial implementation. It seems that each new release of PHP has a
small speed improvement based on some optimization performed, but that
there has been no major
Hi internals:
Currently, I try to port my Traits patch to the latest version of trunk.
Thought about giving you people the chance to play with it again.
Unfortunately, I have some trouble with the parser.
Think, there must have changed quite something in its internal working.
The last time I
Hi internals:
I still have not solved this problem.
An alternative solution would be to introduce additional state into
the compiler globals. Are there any standards or common practices for
such things?
Thanks and best regards
Stefan
On 23 Aug 2009, at 22:47, Stefan Marr wrote:
Hi
for git on the wiki[1] but am not familiar
with git/github.
[1]http://wiki.php.net/vcs/svnfaq#git
On 27 Aug 2009, at 13:01, Stefan Marr wrote:
Hi internals:
I still have not solved this problem.
An alternative solution would be to introduce additional state into
the compiler globals
Dear internals:
Has been a while since we discussed whether the idea
of Traits fits into the programming model of PHP.
To encourage further discussion and experiments,
I managed to update some tests, to fix some bugs,
and eventually to use GitHub to make it accessible to you.
Please find a
/inheritance-versus-roles-176
BTW, I just found this links, and am not involved in any way, but
well, I think Traits could be useful in PHP, too.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http
to be merged. :)
Best regards
Stefan
regards,
Lukas
On 13.10.2008, at 21:12, Stefan Marr wrote:
Hello,
the last time the topic traits has been discussed is already a
while ago.
At this time, there have been two very different opinions out
there, about
how exactly this horizontal reuse
/unsub.php
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax: +32 2 629 3525
that much flexibility.
Just my thoughts, great work though.
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax: +32 2 629 3525
--
PHP Internals - PHP
of semantics
- a patch
And then based on discussion:
- FAQ or common misconceptions
- alternative proposals
- rejected features
- change log
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32
. And I do not find it in the docs either.
static properties should work like normal properties.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
://www.php.net/unsub.php
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
patch,
or, you open a new thread and propose a change, start an RFC, and all that jazz.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP
a E_STRICT warning. That's what we can do for the moment.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi:
On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky alex.howan...@gmail.com wrote:
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but
Hi Alex:
On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky alex.howan...@gmail.com wrote:
Best practice, always choose trait property names carefully/~unique
so that you don't run into conflicts.
Sure, but in this case, I created the conflict intentionally because I
*want* to override it, and
On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron jbo...@openmv.com wrote:
On Fri Jul 22 01:46 PM, Alex Howansky wrote:
Sure, but in this case, I created the conflict intentionally because I
*want* to override it, and I'm not allowed to like I am with methods.
Don't you think that's
Hi Mike:
On Sat, Jul 23, 2011 at 6:49 PM, Mike Stowe mikegst...@gmail.com wrote:
So am I understanding correctly that the initial properties must be identical
both in type and value, otherwise it would throw an error. To me that would
make the most sense as they could be overridden in a
Hi:
I would like to ask for a review of the solution for the following issue.
A patch is currently available at:
https://bugs.php.net/patch-display.php?bug=55214patch=__CLASS__-in-traits.002.patchrevision=1311532096
The problem is that __CLASS__ used in the body of a trait method does
not behave
Hi Johannes:
2011/7/25 Johannes Schlüter johan...@schlueters.de:
Now I use reflection on this:
$rc = new ReflectionClass('C');
print_r($rc-getTraitAliases());
Array
(
[tc] = T1::t1
)
Great, that is nice.
So far so nice but I'm missing the information where C::t1() is coming
Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals
to the teacher.
Another design might offer more freedom/power...
Best regards
Stefan
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2
.
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi:
On 16 Oct 2011, at 04:15, Stas Malyshev wrote:
class_uses - Stefan
Added with:
http://news.php.net/php.doc.cvs/8942
Furthermore, I added the documentation of __TRAIT__, and extended the docs for
__CLASS__:
http://news.php.net/php.doc.cvs/8943
Best regards
Stefan
--
Stefan Marr
of course provide incompatible method implementations. (Which
does not make traits any different from any other way to implement an
interface.)
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
of these mechanisms will lead to a case where a
method is completely missing from the eventual class.
Implementation without any contract.
Yes.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
something? I just had such a case, where my local setup was
insufficient to catch it.
Thanks a lot
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP
.
Thanks to people like Antony, obviously stupid bugs get caught pretty fast.
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP
to normal, that way the list wouldn't be spammed, but some active
contributors would be still continuously bugged.
Does that meant that the committer could get an unconditional email with the
result of his/her commit?
Sounds very reasonable to me.
Best regards
Stefan
--
Stefan Marr
Software
, but perhaps this feature is not
quite mature enough for release just yet?
On a personal note: never tell a mother that her child is ugly.
Please stay constructive. Thanks!
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
between the 'PHP
should be more like Java' and the 'PHP should be more like PHP' people.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi:
On 13 Jan 2012, at 11:13, Stefan Marr wrote:
From the top of my head, it is the handling of __CLASS__ and the handling of
static variables in methods. You did not mention that, is it taken care of
explicitly, or do traits now share static state? The later would not be
intended
relevant changes from the top of my
head.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
request: could you separate out the
optimizations you do in zend_language_scanner.l? I think it would be better to
have the proper use of interned strings committed on their own. Especially,
since they regard not only trait-related functionality.
Thanks
Stefan
--
Stefan Marr
Software Languages
) at zend.c:1264
#4 0x000100208683 in php_execute_script (primary_file=0x7fff5fbff200) at
main.c:2476
#5 0x00010049bb83 in do_cli (argc=2, argv=0x7fff5fbff4b0) at php_cli.c:983
#6 0x00010049d8c5 in main (argc=2, argv=0x7fff5fbff4b0) at php_cli.c:1356
--
Stefan Marr
Software Languages Lab
Hi Dmitry:
On 14 Jan 2012, at 01:24, Stefan Marr wrote:
On 13 Jan 2012, at 19:53, Stas Malyshev wrote:
trait foo {
public $bar = __CLASS__;
}
Breakpoint 3, zend_do_early_binding () at zend_compile.c:4602
4602 zend_error(E_COMPILE_ERROR, Invalid binding
type
Jan 2012, at 23:22, Stefan Marr wrote:
I was thinking that we might want to handle that in zend_do_early_binding but
usually these ops get changed to NOPs after they have been evaluated.
And that's not what we need when the op_arrays are shared, I think.
However, the current implementation
-time constants referring to the actual place
where they occur.
Adapting them to reflect the using classes would at least not seem to be the
intuitive semantics, I think.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels
, but the code seems to look good
and the tests are there and work, too.
Thanks Dmitry!
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP
://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Hi:
On 02 Mar 2012, at 01:33, David Soria Parra wrote:
just a heads up. The PHP_5_4 branch is open for commits again.
Thanks to Stat and you for all the work!
When is cycle for 5.4.1 going to start?
I got a few traits-related patches waiting for it.
Thanks
Stefan
--
Stefan Marr
Software
?
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
as hints for the standard usage of a
trait, but can be changed during composition.
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals
On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
Rasmus Lerdorf wrote:
No, not ok. We will call the next release whatever we like. People who
have written books or articles about PHP 6 inferring they knew what the
final state of PHP 6 would be were misguided. We never got to the point
1 - 100 of 170 matches
Mail list logo
