Re: [PHP-DEV] [RFC] [Under Discussion] Constants in traits
Hi Nicolas: > On 22 Jun 2022, at 17:31, Nicolas Grekas wrote: > > > I'd like to start a discussion on an RFC to allow defining constants in > > traits. > > https://wiki.php.net/rfc/constants_in_traits > > > > I'm looking forward to your feedback, including corrections on English > > wordings. > > > > Thanks! > > > > -- > > Shinji Igarashi > > I am initially lukewarm. One thing not addressed in the RFC that should be: > Why were constants left out of traits previously Hm. This isn’t something that I remember coming up specifically back then. If it had been discussed in more detail, I’d probably have included it in the RFC. So, my working assumption is: it wasn’t something I really thought about. > and what has changed to make them make sense to include now? (I don't > recall, honestly, so I have no strong feelings one way or the other yet.) I am not sure there are reasons to specifically exclude them though. The RFC, reading over it briefly, and having been away for very long from the topic, seems sensible to me. Taking a very restrictive approach, seems sensible to me, too. > I'm also wondering why the default value of a const (and a property) could > not be changed by the class importing the trait? This sometimes hits me and > the original RFC doesn't explain why this is needed. For constants, I’d lean towards not allowing changes. If you need to parameterize the trait with a value, having an abstract method return it seems a much clearer way of doing it. Then all parts of the system know “it’s not a constant” and I need to cater for different values. The reason for the strict policies on property conflicts was to keep it simple. Be conservative, and avoid silent bugs. Please take everything I say with an extra pinch of salt. It has been a long time. Best regards Stefan -- Stefan Marr School of Computing, University of Kent https://stefan-marr.de/research/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Complete traits redesign for 5.5
Hi Dmitry: On 18 Dec 2012, at 12:37, Dmitry Stogov wrote: I'm going to take a deep look into trait implementation and provide a better solution for 5.5. The current implementation is really wired and makes a lot of troubles for maintenance and each new fix, makes new troubles :( Sorry, that's mostly me lacking understanding of the PHP internals. And there are many wired corner cases that have to be covered. I'm going to work on it with top priority during last few days and then send a patch. Thanks for looking into it. I'll be able to test things over christmas. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits behavior still up in the air in 5.4
Dear Stan:
On 01 Aug 2012, at 01:23, Stan Vass wrote:
1. Name collisions between a trait method and a class method using the trait
go unreported, the class silently shadowing the trait method:
trait T {
function foo() { $this-bar; }
function bar() { echo 'trait'; }
}
class C {
use T;
function bar() { echo 'class'; }
}
$c = new C;
$c-foo(); // class
Proposed behavior: Fatal error on collision, unless the method is imported
with a unique name using the { ... as ... } syntax.
This happens to be 'by design'.
The methods in the class have *always* higher precedence.
This is the same 'overriding' behavior used for inheritance.
From my personal perspective, changing this would lead to a major inconsistency
with how subclassing works.
If you disagree, please open an explicit thread for this problem and report it
in the bug tracker.
2. Using as syntax when importing a trait does NOT rename a method, but
creates an alias CLONE, the original method still callable.
trait T {
function bar() { echo 'trait'; }
}
class C {
use T { bar as foo; }
}
$c = new C;
$c-bar(); // trait
Proposed behavior: the original name should be only accessible within the
trait and its methods, not from the class methods or by calling the class
instance's methods from outside.
Again, this happens to be 'by design'.
PHP is a rather dynamic language, and we happen to have things like $c-$foo();
where $foo is a string. Renaming is technically not reasonable, and would also
lead to major confusion when metaprogramming is used.
Bye the way, this is documented:
https://wiki.php.net/rfc/horizontalreuse#renaming
3. Properties silently collide in traits and classes.
trait T1 {
private $foo;
trait T2 {
private $foo;
}
class C { use T1, T2; } // No error.
Proposed behavior: An error is produced only when the properties differ in
visibility or a default value, which is clearly insufficient to determine
they're used for the same purpose, and hold the same data. Instead they
should use the same logic as method conflicts: fatal error on name collision.
Alternatively, each trait property whould be accessible within the trait that
defines it, not from other traits used in the same class, or the class itself.
Please read
https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate carefully.
Again, this is intended behavior.
If you want to be notified of such collisions, please use E_STRICT.
4. The documentation says static propeties can't be defined by traits. Yet
they can.
I don't know what's the bug here: a doc bug, or a code bug. For consistency,
static properties should work, if instance properties work. Nothing is gained
supporting it half-way.
Could you please point me *exactly* to the paragraph where we have something
written about static properties? I do not see that I wrote anything special
about static properties in the RFC. 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits behavior still up in the air in 5.4
what's the bug here: a doc bug, or a code bug. For consistency, static properties should work, if instance properties work. Nothing is gained supporting it half-way. Could you please point me *exactly* to the paragraph where we have something written about static properties? I do not see that I wrote anything special about static properties in the RFC. And I do not find it in the docs either. static properties should work like normal properties. Sure. From the manual page for traits: Static variables can be referred to in trait methods, but cannot be defined by the trait. This paragraph is then following by a code example using function-static variables as what seems like an example for a replacement for static trait properties, strongly suggesting the former aren't supported. Yet they are. The RFC seems to also give examples of method-level static variables, and I honestly can't see how this is related to traits or trait/class-level members at all. I assume we are talking about: http://php.net/manual/en/language.oop5.traits.php Static variables and members/properties are not related at all. The writer of the documentation didn't get the wording correct. Please feel free to submit a patch. The example code given in the manual is correct. (Example #9 Static Variables) The section heading is misleading. It is not about static members, and members and variables are not synonym. Members are synonym with properties, and properties can be static. Static variables are local to a class, not to a trait. Traits do not exist at runtime, they are flattened into classes. With regard to your other mail. I didn't get a bug report with the keyword trait in it. If you want me to clarify the confusion, please give me a link. Best regards Stefan Stan -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits behavior still up in the air in 5.4
. No property collisions. Fatal errors. It's very simple. There is nothing simple in PHP... People don't like fatal errors, especially not for things they intend to just work. From my example above, the kind of guarantees you expect are just not something that is part of what PHP is. I assume we are talking about: http://php.net/manual/en/language.oop5.traits.php Static variables and members/properties are not related at all. The writer of the documentation didn't get the wording correct. Please feel free to submit a patch. I've submitted a doc bug. No one want to fix it since they think it's PHP that's wrong, not the manual. I can't do anything more about it. Here's the link: https://bugs.php.net/bug.php?id=62156 I don't know who 'they' are, but I am the insane (thanks for that attribute) person who wrote the RFCs and the implementation. So, either you accept my answer that static properties just work, and you fix the manual by providing a greatly appreciate 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits behavior still up in the air in 5.4
to integrate with them. And the main problem here is that PHP got dynamic properties. If you want to change the semantics to 'local-to-trait'-by-default fields, please provide a patch and an RFC. I won't stop you. On the contrary, it is certainly an appealing option. Throwing a FATAL however is not an appealing option. We are already pretty strict when we see that it is most likely a bug. And we give you 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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
Hi Andrew: On 25 Jul 2012, at 22:50, Andrew Faulds wrote: I think someone (perhaps me) should write an RFC on how to write an RFC Note that a new page create on the wiki in the RFC namespace comes with a template that gives some guidance on how to write an RFC. Lukas based it on my original Traits RFC, since that one was considered to be a nice example. At least it was kind of complete with regard to the essential parts of an RFC: - intro - motivation - full description (up-to-date following the discussions) of the proposed feature - with examples and use cases - summary 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 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enforcing final in traits
On 04 May 2012, at 21:46, Hannes Magnusson wrote: On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar sc...@macvicar.net wrote: This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. The methods in the class always take precedency. However, the final keyword might just be something I overlooked. It sounds sensible that if the final is not explicitly removed during composition to treat it as what final was meant for and check it against the methods defined in the class body as well. Scott, could you elaborate a bit of the use case of final in a trait? it also ignores visibility abstract and static.. abstract is not ignored. An abstract method in a trait expresses a requirement to the host class (using class). In general, the ppp visibilities are seen 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update for Todays Migration
Hi David: On 18 Mar 2012, at 19:00, David Soria Parra wrote: Hi Internals, we will start migrating the php-src repository today and SVN access will be closed by 21:30 UTC. Thanks do Alexander Moskaliov we now have a much better, rewritten Mail script. Thanks to Florian Anderiasch we have a bugweb script. Thanks! I added a wiki page for the workflow at http://wiki.php.net/vcs/gitworkflow. So far nobody has added questions to the gitfaq or the asked questions about the workflow (except for stas). The workflow has one practical drawback over the current sparse checkout one. For me, switching branches also implies redoing configure and make, doesn't it? That adds quite a bit of overhead to build and test times. Thus, I would suggest to document the workflow with different folders for the major branches. Or, in case there is a better way, please let me know. 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
Re: [PHP-DEV] Git Migration: Status Update
Hi David: On 03 Mar 2012, at 22:58, David Soria Parra wrote: (1) Pull requests on github.com go to the git-pull mailinglist. Make sure you subscribe to it. (2) Johannes is working on an interface that allows people with valid PHP user accounts to close pull requests. (2) Fix the bugsweb integration, so that references to bugs inside the commits will work. Florian is working on it. (4) FAQ Will there be an integration with pull requests and the bug tracker, or remains attaching patches the preferred way? What is the new preferred replacement for a sparse SVN checkout + single commit per change? As I understand it, currently, we try to have a single commit for all branches (PHP_5_n, and trunk). How is that supposed to be done with git? From reading https://wiki.php.net/rfc/dvcs#workflows, I assume, all branches need to receive separate commits + pushes? 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
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
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 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
Re: [PHP-DEV] Bug #61033 __FUNCTION__ doesn't report correctly in alias trait methods
Hi Marc: On 09 Feb 2012, at 22:36, Marc Easen wrote: The reason why I feel this should be changes to reflect the actual called function name is that one of main uses of the __FUNCTION__ constant it to refer back to the function that is currently running, for the use recursive functions: I still maintain the position that __FUNCTION__, as __LINE__ and __FILE__, is supposed to be a lexical constant. (In retro-spective, adapting __CLASS__ to do even more magic might have been a mistake, from a conceptual point of view.) So far, I was refraining from proposing any additions to the RFC before 5.4 is finally out and we see how it is used in the wild. But since recursive function calls are indeed a problem, we should look for a better solution. I think, `self` is already a keyword anyway, perhaps we can use that for self-referential/recursive function calls in traits? 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 To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test execution and created files
Hi: Pierre recently committed a test that just bit me. (see below) After I run `make test` my personal test.php file was gone in my trunk folder. Well, nothing lost here, but this wasn't exactly a nice surprise. Would it be a reasonable change to make the tests execute in a temporary directory created exactly for that purpose? Thanks Stefan On 18 Jan 2012, at 21:22, Pierre Joye wrote: pajoye Wed, 18 Jan 2012 20:22:47 + Revision: http://svn.php.net/viewvc?view=revisionrevision=322456 Log: - add test for bug #60771 Bug: https://bugs.php.net/60771 (error getting bug information) Changed paths: A php/php-src/branches/PHP_5_3/Zend/tests/bug60771.phpt A php/php-src/branches/PHP_5_4/Zend/tests/bug60771.phpt A php/php-src/trunk/Zend/tests/bug60771.phpt svn-diffs-322456.txt-- PHP CVS Mailing List (http://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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
On 17 Jan 2012, at 06:42, Stas Malyshev wrote: Hi! Now especially for traits it delays resolution of special constant __CONST__ til run-time. Looks good, I don't see any problems with it so far. If nobody else does, let's commit it, I only had a chance to have a very brief look, 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
Hi: On 16 Jan 2012, at 11:15, yoram bar haim wrote: If we want __CLASS__ to be resolved at runtime (at list in case of trait), then what about __FILE__ and __LINE__ ? should they be resolved at compile time and reflect the original code in the trait or should they reffer to the using class (which is a problem for the __LINE__ ...) ? I would argue that __FILE__ and __LINE__ are not referring to conceptual entities, but the literal code. And, I guess, they are mostly used for debugging purposes to identify the relevant code. Thus, I would not change them, but keep them as compile-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 / 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
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
Hi Dmitry:
After Stas nice and encouraging words, I had another look.
But to me it seems that I am not able to get to any of the relevant bits via
the scoping infos in the globals. And I do not see how we could encode
something into ZEND_CLASS_NAME.
But I don't have a good overview of the engine, so I probably just miss the
obvious.
And Stas, to assuage your pain:
Yes, in the worst case, Dmitry's patch would need a null check on EG(scope) and
we make it return NULL for those properties.
But I bet, someone with a little more insight will have a solution.
Best regards
Stefan
On 14 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 of ZEND_CLASS_NAME you proposed relies on
EG(scope) which is not set for the case below.
I might be able to look into it further on Monday, but not earlier,
unfortunately.
Best regards
Stefan
trait Foo {
public $c = __CLASS__;
}
class Bar {
use Foo;
}
$bar = new Bar();
var_dump($bar);
--
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 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
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
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);
(gdb) p opline-opcode
$1 = 159 '?' // == ZEND_CLASS_NAME
What would be the best approach to handle the case of property definitions?
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 of ZEND_CLASS_NAME you proposed relies on
EG(scope) which is not set for the case below.
I might be able to look into it further on Monday, but not earlier,
unfortunately.
Best regards
Stefan
trait Foo {
public $c = __CLASS__;
}
class Bar {
use Foo;
}
$bar = new Bar();
var_dump($bar);
--
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
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
Hi Dmitry: On 13 Jan 2012, at 10:36, Dmitry Stogov wrote: Recently we've found a huge problem in PHP traits implementation. Thanks for taking care of it, but just to be explicit here: I pointed out the implementation details in the various discussions. I never made it 'a secret' that there is copying going on. I even tried to point out the potential for this kind of sharing. See for instance: http://markmail.org/message/okhq2vp7h3yuegot And the comment of the initial commit: http://svn.php.net/viewvc?view=revisionrevision=298348 Sorry, but I am a bit annoyed that 'the community' does not care enough about reviewing such engine changes. I got plenty of help from various people, but 'discovering such a huge problem' so late in the process points out certain problems. Anyway, back to the technical details. It performs copying of each op_array (with all opcodes!) for each method used from trait. This not only makes traits extremely slow and reduce effect of opcode caches, but also prohibits extensions from modifying op_array in some way, e.g. extending op_arrays with additional information in op_array.reserved* fields. As result some extensions (e.g. xdebug and some Zend extensions) will just crash on traits usage. As I understood the copying was done only for proper handling of __CLASS__ constant in trait methods. I think it's too radical solution. I've introduced ZEND_CLASS_NAME instruction instead and made op_arrays to share their opcodes (in the same way as inherited methods). The only difference that methods from traits may be renamed. 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. Will check whether we got that documented with a test. The patch is attached (it requires executor/scanner/parser regeneration) I would like to commit it into 5.4 and trunk. Note that the patch makes binary compatibility break and can't be applied to 5.4.* after 5.4.0 release. I know that applying it may delay the PHP 5.4.0 release, but it's better to fix the problem now. I would be in favor of getting it into the process now, too. Especially if it breaks binary compatibility. I will take at a look at the patch later today. 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
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
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. Will check whether we got that documented with a test. Seems to work fine, is checked with a very basic test in PHP_5_4/Zend/tests/traits/language013.phpt 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
Hi Lester: On 13 Jan 2012, at 11:51, Lester Caine wrote: If developments like this slow down the general performance of PHP There shouldn't be any significant performance impact of the traits addition to the engine. Traits only cost you if you use them, and their cost is restricted to compilation time. With an adapted opcode cache, and with Dmitry's optimization even that cost should be gone. There is some general performance impact, and that comes from additional fields in the class struct. Thus, every class takes slightly more memory. Beside that, I do not recall performance 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
Hi Dmitry: On 13 Jan 2012, at 10:36, Dmitry Stogov wrote: As I understood the copying was done only for proper handling of __CLASS__ constant in trait methods. I think it's too radical solution. I've introduced ZEND_CLASS_NAME instruction instead and made op_arrays to share their opcodes (in the same way as inherited methods). The only difference that methods from traits may be renamed. The patch is attached (it requires executor/scanner/parser regeneration) I would like to commit it into 5.4 and trunk. Note that the patch makes binary compatibility break and can't be applied to 5.4.* after 5.4.0 release. I looked at the patch, looks good as far as I can see. The comment in zend_traits_copy_function (has a typo 'destroied') makes me wonder what it means exactly. Does it mean we got a memory leak with regard to trait aliases? And, I would have one stylistical 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 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
Re: [PHP-DEV] Urgent patch for traits in PHP 5.4
Hi Stas:
On 13 Jan 2012, at 19:53, Stas Malyshev wrote:
I've done some checks and discovered __CLASS__ behaves somewhat strangely
with traits. COnsider this code:
?
trait foo {
public $bar = __CLASS__;
function bar() { var_dump($this-bar); }
}
class foofoo {
use foo;
}
class foofoo2 {
use foo;
}
$a = new foofoo();
$a-bar();
$a = new foofoo2();
$a-bar();
echo OK!;
Before the patch, it prints $this-bar as NULL.
Yes looks like another hole in the things I covered :-/
The attached test defines the intended behavior. Like you said, __CLASS__ is
expected to give the using class. My testing covered so far only the handling
of __CLASS__ in methods.
The fatal you see in the patched version is coming from Dmitry's new opcode,
which is probably doing already almost the right thing.
Will try to look into it tomorrow.
Until then, the stacktrace below gives some details on what is going on.
Best regards
Stefan
Breakpoint 3, zend_do_early_binding () at zend_compile.c:4602
4602zend_error(E_COMPILE_ERROR, Invalid binding
type);
(gdb) p opline-opcode
$1 = 159 '?' // == ZEND_CLASS_NAME
(gdb) bt
#0 zend_do_early_binding () at zend_compile.c:4602
#1 0x00010025030e in zendparse () at zend_language_parser.c:230
#2 0x00010025a4cc in compile_file (file_handle=0x7fff5fbff200, type=8) at
zend_language_scanner.l:579
#3 0x0001002c5ab6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) 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
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
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi: On 23 Dec 2011, at 01:14, Stas Malyshev wrote: BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl, Javascript (to some measure), etc. don't have typing as far as I know. Comparing PHP to statically compiled strictly typed languages does not seem very useful to me. So could you clarify what do you mean? Perhaps the newest kid on the block deserves some reference for making optional typing more mainstream and being more radical about being checkable documentation: http://www.dartlang.org/docs/technical-overview/index.html Dart's type system is not sound, and the design goal is to never (NEVER) interfere with execution semantics. It is more radical than previous research systems with its not-sound approach of making generics understandable, but people seem to appreciate that in practice. It might give the necessary example to bridge the worlds 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] some notes about traits
Hi Rasmus: On 16 Nov 2011, at 01:17, Rasmus Schultz wrote: I knew about the traits features in Scala, and I guess I assumed this would be similar - not so. Right, they are not the same. PHP's traits are much closer to the notion of traits introduced in the Smalltalk world, while Scala's traits are rather like mixins as for instance in Ruby. Aside issues like typing and whether that type information is preserved, the main difference is that PHP's traits do not use implicit conflict resolution. I believe the key to understanding traits, is understanding that traits are in fact an implementation detail - an artifact that does not really change or affect the nature of OOP in PHP as such, and by design, should not. I understand that now - thank you :-) From my perspective, a key difference from classes and interfaces, is that traits have no meaningful use at run-time - no type-hinting and with no real reflection-features that reveal the details. They cannot implement interfaces for classes, but classes can use them to implement interfaces. Traits just provide a set of method implementations that can be aggregated by classes. So in a sense, they're a design-time tool for the programmer. I like that explanation, thanks! So I guess my remaining quibble is that the documentation needs to relay this somehow - with a basic real-world example that actually uses an interface too, to clarify the difference, and to demonstrate how this tool use useful in conjunction with class and interface declarations. Hello world really doesn't explain anything, other than the syntax. [...] This may be a little too magical for an example in the documentation though - and doesn't demonstrate interfaces. I'll ponder this and post a better example if I can think of one... :-) As someone else already pointed out, there are tools to contribute such nuggets to the documentation. Please submit a patch. And just one other comment: var_dump($test instanceof CartBehavior); // = false Why would it be beneficial to throw an exception here? CartBehavior is a trait, and not a class or interface. The instanceof operator has no meaning for traits - it always returns false. You could argue that false is the expected result - I would argue that the only reason this happens to work at all, is because traits internally are classes. Suppose you thought you were actually doing a meaningful type-check of some sort? If by mistake you put a trait-name where you meant to put the name of an interface or class, such an error could be very hard to spot. While I agree that it can be hard to spot, I would usually advocate for less intrusive alternatives. Hmmm, well, I could put in a warning in strict mode, I guess. But that would require a consistent handling within all the other APIs we got, too. Especially is_a is such a candidate. And changing is_a seems to be a non-trivial thing. So, I will need to look carefully at that. Would be great if you could file a bug report for that. I hope this feedback is useful :-) Yes it is. I think it is especially important that other people actually write down their understanding of the mechanism. Blog posts, mailing list posts, improved documentation, they are all important. 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
Re: [PHP-DEV] some notes about traits
that the practical overhead does not justify this conceptual burden. I apologize if I'm somehow missing the big picture here, or maybe I set my expectations too high - but my first impression of this feature is that it's crippled and somewhat half-baked... If there was a deliberate and logical reason for not supporting these features, I would like to understand why. If not - great work so far, 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 / 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
Re: [PHP-DEV] CI for 5.4
Hi Ferenc: On 03 Nov 2011, at 19:01, Ferenc Kovacs wrote: Of course there are ways to improve the current setup, I listed those ideas at https://wiki.php.net/rfc/jenkins#future_plans Very nice. I don't know Jenkins, but would it be possible to mail the author of a change in case it breaks 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CI for 5.4
Hi: On 03 Nov 2011, at 20:15, Ferenc Kovacs wrote: The usual setup is that you have a mailing list/alias which always gets a mail about the build results (which can also be customized in detail, when to mail, etc.) and optionally you can notify the person whose commit break the build. If I get a personal notification via mail, if I break something, that kind of guarantees my attention. Using IRC is to distracting, so that is not an option for me. Sorry. If I am the only one who would use it, then don't bother. But if I can simply opt-in for it somewhere, that would be great. 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 Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] CI for 5.4
Hi: On 04 Nov 2011, at 00:12, Ferenc Kovacs wrote: I almost forget to mention, but the email notification also supports defining different recipients for each event, so for example the commiters could still get the notification for each of their commits/builds until the build is back 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 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
Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
Hi Anthony: On 24 Oct 2011, at 07:06, Anthony Ferrara wrote: Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Traits do not provide any provisioning for handling state. The original RFC was correct in that traits should not have any state. However the implementation differs from the RFC significantly in that respect. Please read the RFC. Thanks! Traits do not provide any provisioning for handling state. However, every behavior needs state to operate on, otherwise it could be just a static functional helper method. Thus, trait code will either need to use accessors, which is favorite way to go since it provides full traits semantics, or they use properties, which is possible but rather a convenience feature. Thus, the goal for a consistent language design is to raise awareness of the problem, promote the use of accessors, and break early in case the changes to a trait is potentially problematic for a class using it. This results in the following rules: [...] This is purely a matter of consistence with the dynamic nature of PHP. We allow explicit naming of the properties, and that is all. There is no handling of any semantics, there is no conflict resolution, there is no state merging, splitting or what ever you would need to have a powerful enough semantics for stateful traits. Thus, I maintain the position that our traits do not provide any handling for state. However, they break early when a conflict/incompatibility is assumed. That is all, nothing more. Traits can explicitly define properties which actually prevent the parent class from changing this. What is a parent class with regard to a trait? That concept does not exist. See these two examples: http://codepad.viper-7.com/fqD91I and http://codepad.viper-7.com/DFDpqM That is not a parent class, that is a using class or user, not a parent. So there is absolutely 100% support for state here. I could understand if it was a dynamic property or the like, but this is really state. As I outlined above, I disagree with that position. It does not mean that traits handle/have state! That only means that we cater for the nature of PHP. Perhaps the difference is academic, but it is quite important for me. We cannot do without that breaking early property, because being conservative here seems the best option we have at the moment. Bailing out in case of possible conflicts is the only way to avoid subtle bugs. But the semantics of the properties are exactly as if they are defined in the class, which means that there is no notion of state what so ever associate with the trait. It is only realized in the final class, and the corresponding object. The trait merely declares it. The relevant part of the RFC: https://wiki.php.net/rfc/horizontalreuse#conflict_resolution We abandoned the idea of an explicit exclude operator long ago. (I think it was never in the PHP SVN.) Thus, the situation you describe cannot occur in the sense that a method is missing from the class. However, you can of course provide incompatible method implementations. (Which does not make traits any different from any other way to implement an interface.) The situation can absolutely happen simply with the conflict resolution (as you say). I think, I do not understand what you are getting at. The problem that cannot occur is that you get a runtime error because a method is completely missing from a class. You can neither exclude nor rename a method. We do not have exclude, and we only got aliasing. Neither 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 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
Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
Hi Anthony: I will not comment on the original question of this thread, but felt obliged to point out some details where my understanding differs from what I understand from your explanation. On 22 Oct 2011, at 07:25, Anthony Ferrara wrote: Well, I have a few opinions on this that I think are worth sharing: 1. If this change is made, we no longer would have mixins, but would have regular multiple-inheritance (With all the issues associated with it). Note that I said mixins and not traits. That's because since these were implemented with state (member properties), they are not traits as implemented, but regular mixins. (Yet another gripe, but that's slightly off topic). Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Traits do not provide any provisioning for handling state. What you observe is that PHP is a very dynamic language when it comes to the definition of fields. And that is what traits also take into account. We do the minimal possible thing, to keep the WTF factor low, but there is no real support for state. And as someone else pointed out: the main difference is indeed the difference between linear application (mixins) and order-less composition (traits). There's a much bigger problem though. How would you solve the problem where a class uses a trait that implements an interface, but you don't pull one of the methods through (for example, you exclude it in the use clause)? The relevant part of the RFC: https://wiki.php.net/rfc/horizontalreuse#conflict_resolution We abandoned the idea of an explicit exclude operator long ago. (I think it was never in the PHP SVN.) Thus, the situation you describe cannot occur in the sense that a method is missing from the class. However, you can 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 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
[PHP-DEV] Re: typehinting traits
Hi Ferenc: On 17 Oct 2011, at 19:41, Ferenc Kovacs wrote: Hi Stefan, Multiple people asked me that how they can expect/check that a given object uses a trait or not. Of course one could write the concrete methods as a trait and always use a given interface for typehints, but I can't see why shouldn't instanceof and typehints in general work for traits. Is the any technical or maybe theoretical argument against this? Originally I proposed traits including the semantics that traits directly implement interfaces. The discussion is somewhere here: http://www.mail-archive.com/internals@lists.php.net/msg33935.html I think Sebastian was the person with the strongest opinion on that particular issue: http://www.mail-archive.com/internals@lists.php.net/msg33948.html And I tend to agree with him. Currently I think along the following lines: A trait is not a full unit of reuse! A class is. Don't use traits where you should use classes and composition. Traits do not guarantee anything, if you want to be sure your invariants hold, use classes and composition. Traits allow to reuse behavior in a much more flexible way, but they do not replace classes. And, well, then there is this: https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_implement_interface That should make sure that people can use interfaces for the purpose envisioned here. For reference, there is also: https://bugs.php.net/bug.php?id=55613 But aside of the things I said before: - theoretically: keeping interfaces and traits apart is a good, clean language design decision. - practically: people LOVE ugly languages, because they get things done So, well, I can't claim anything about value here. The current situation might be more friendly 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 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: typehinting traits
Hi: On 17 Oct 2011, at 22:59, Ferenc Kovacs wrote: Thanks again for the clarification and for your work on traits! Jeff Carouth pointed out( https://twitter.com/#!/jcarouth/status/126030715514138624) that we have class_uses() (https://bugs.php.net/bug.php?id=55266), would be nice having that in the documentation. Until now I did not even know I had karma... Here you go: http://news.php.net/php.doc.cvs/8942 And well, I have neither a clue about the toolchain nor anything related to that XML format. So, a review not only content but also style-wise is more than welcome. 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
Re: [PHP-DEV] 5.4 undocumented stuff
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 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
Re: [PHP-DEV] Issues with Traits / php crashes
Hi Harald: On 16 Oct 2011, at 20:31, Harald Lapp wrote: with the current php-5.4 beta my processes are dying, but with the lates snapshot, not -- i still get the message: There have been a number of bug fixes since the last beta. The list is here: https://bugs.php.net/search.php?search_for=traitboolean=0limit=30order_by=direction=DESCcmd=displaystatus=Allbug_type=Allproject=Allphp_os=phpver=cve_id=assign=author_email=bug_age=0bug_updated=0 If it does not crash with the snapshots, that is what I understand from your sentence, then those fixed bugs might already be the ones you encounter. my question is: is there anything i can do to track this problem down, to get a useful backtrace / core dump or any other information, that would count as useful information for filing a bug-report? as it is know, i have nothing in my hands besides the info, that it's crashing ... Since you already suspect the traits implementation, how about your unit tests in that regard? I would guess they might be run easily with the CLI version of PHP. That is at least the way I narrow down the origin of such crashes. Best regards Stefan thanks in advance! harald -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection, Traits, Aliasing
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
from. In the reflection code I'm currently iterating over
ce-trait_aliases and can't find where I can get the information from.
Actually I'd be even interested in getting all important methods and
their origin. Stefan, do you know where I can find the information or
would we have to store it additionally?
The functions do not store that information, so there are basically
only two approaches, I see:
Either, factoring out the code which is doing the flattening, conflict
resolution, and class composition into something which could be easily
shared by both the reflection and the engine, and then re-doing it on
demand in the reflection,
or we extend zend_function by an origin pointer.
Not sure what the better tradeoff is general memory overhead vs.
cache-able pay-as-you-go overhead.
Best regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: Bug #55214 [Com]: use of __CLASS__ within trait returns trait name not class name
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 as expected based on the advertised metaphor that traits
are some kind of compiler-assisted copy'n'past.
This patch provides this semantic, thus, __CLASS__ will correspond to
the class name of the class where the trait is actually used.
However, my solution is very hackish: I changed the implementation of
how __CLASS__ is handled, and instead of setting the class name on the
zval, I set the zval to IS_NULL, and one of the unused data members as
a flag identifying this NULL value to be special.
This flag is later checked when the methods are actually copied into
the class, and the zval is replaced by the actual expected class name.
To be able to garbage collect the created zval later, it is included
in the list of literals of the method.
However, I do not have any clue on what kind of invariants are
associated to literals, nor what there actual semantics is supposed to
be.
This is mainly because of our implicit policy of keeping the engine
code free from any comments.
Thus, I would really like a comment on this patch, otherwise I will
commit it next week and also add the missing __TRAIT__ magic variable
to mirror the __CLASS__ behavior in a trait.
Thanks a lot
Stefan
PS: just noted there might be at least one more bug. note to self: add
a test for a traits that is used by a trait that is used by a class
Original Message
Edit report at https://bugs.php.net/bug.php?id=55214edit=1
ID: 55214
Comment by: g...@php.net
Reported by: chris dot rutledge at gmail dot com
Summary: use of __CLASS__ within trait returns trait name not
class name
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Ubuntu
PHP Version: 5.4.0alpha1
Assigned To: gron
Block user comment: N
Private report: N
New Comment:
Ok, updated the patch and would like to ask for a review.
This is still hacky, but now I use the literals of a function to be
able to clean up the zval for the __CLASS__ name. Thus, the memory
leak should be fixed.
Think we will still need a __TRAIT__ to mirror __CLASS__ and to get
the trait name itself when that is required.
The test case is missing in the patch:
--TEST--
Bug #55214 (Use of __CLASS__ within trait returns trait name not class name)
--FILE--
?php
trait ATrait {
public static function get_class_name() {
return __CLASS__;
}
public function get_class_name_obj() {
return __CLASS__;
}
}
class SomeClass {
use ATrait;
}
$r = SomeClass::get_class_name();
var_dump($r);
$o = new SomeClass();
$r = $o-get_class_name_obj();
var_dump($r);
?
--EXPECT--
string(9) SomeClass
string(9) SomeClass
Previous Comments:
[2011-07-24 18:28:16] g...@php.net
The following patch has been added/updated:
Patch Name: __CLASS__-in-traits.002.patch
Revision: 1311532096
URL:
https://bugs.php.net/patch-display.php?bug=55214patch=__CLASS__-in-traits.002.patchrevision=1311532096
[2011-07-23 17:53:25] g...@php.net
I attached a patch of how a fix could be done.
I have to admit that it is hacky, but I think this is the expected
behavior with respect to the metaphor of compiler assisted
copy'n'past.
However, the patch is problematic, since it introduces a new memory leak.
And I do not have a good strategy yet to fix it.
Not sure how another patch could work, but the general idea is that
__CLASS__ is not actually defined inside a trait (BTW: we should add
__TRAIT__, too, yes).
Thus, it resolves to a IS_NULL value.
And as it happens to be, IS_NULL makes all is data members invalid,
and I use that to indicate that it isn't actually a NULL value but
that I want to fix it up with the class name when the method is
actually flattened/copied into the class.
The problem with the memory leak comes from the fact that copying the
method is not actually done deeply but shallow. And, I do not know how
to free only my fixed up names/ZVALs :-/.
[2011-07-23 17:45:28] g...@php.net
The following patch has been added/updated:
Patch Name: __CLASS__-in-traits.patch
Revision: 1311443128
URL:
https://bugs.php.net/patch-display.php?bug=55214patch=__CLASS__-in-traits.patchrevision=1311443128
[2011-07-23 14:17:24] fel...@php.net
It's simple to add the __TRAIT__ one, just like __CLASS__ does.
But making a more magic __CLASS__ to reflect the class that called
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
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 also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
After some more thought, my take on this is that those properties are
not compatible, and we do the only simple thing possible and raise an
error as soon as possible, because the trait might have changed to
something that is not compatible with the class and the developer has
to be made aware of that.
While traits do not support state per se, we defined a minimal set of
rules so that the use of properties which conflict in their semantics
breaks as early as possible and noticeable to the developer.
Please refer to
https://wiki.php.net/rfc/horizontalreuse?#handling_of_propertiesstate
for the exact set of rules defined currently.
These rules (rule 1) define that properties are considered
incompatible if they differ in their initial value.
Thus, the case you see here is, according to the rules defined in the
RFC, a bug.
And after looking at the implementation, it turns out that I just
forgot to check one of the return values of the compare function.
Thus, this is fixed as per
http://svn.php.net/viewvc?view=revisionrevision=313632
Best regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
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 I'm not allowed to like I am with methods. Don't you think that's inconsistent? The short answer is it's not a bug but maybe an implementation issue... should it be an E_WARNING instead of E_STRICT? At least. Consider the situation where I'm using classes/traits from somebody else's library that I may not be intimately familiar with. I'll have to know what every one of their properties is named so I can plan my code accordingly -- else I'll silently start getting their values in what I think are my variables. If their trait grows that complex, with its own set of invariants, it is a clear sign that it should be a class instead. Traits are supposed to be a very light-weight mechanism for reuse of behavior. Classes already provide you with the necessary means of encapsulation you are asking for here: but traits do not do that. If you want to reuse a trait that is that complex, consider to use it in a separate class, which is then used in a composition in the class were you originally were going to use the trait directly. Traits do not allow to be reused without knowing their internals. The metaphor of a compiler-assisted copy'n'past mechanism hints at that. At least that is my interpretation of the topic. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
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 inconsistent? Agree I do not agree, because for methods there is for most cases a way around. You can introduce a new alias for the same behavior and use that from the method which is overriding the original method name of the trait. Thus, there is a flexible way to compose behavior, and that is what we do everyday. State how ever, does not come with that property, and the last time we discussed different ideas in that direction they were deemed to be complex. So that traits can keep their own private state (Ben Schmidt's idea) One of those ideas should definitely be reconsidered for a later version of PHP, but for the moment, I would prefer to concentrate on getting bug-free what we have already and gather some experience on how it is actually used in real-world scenarios. In the end, if you trait is to complex and can 'break' easily, I think that shows that it is worth to be implemented as a class, and you might use instead a trait that provides you with the necessary delegation functions. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
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 construct or other method. Yes, they have to be perfectly identical. Any difference indicates, in this strict model, a potential conflict and different semantics of that particular property i.e. the state. Since we do not provide any means to manage such conflicts, we bail out as early as possible and ask the programmer to fix his code by ensuring everything is compatible. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf 2.60+ support
Hi: On 15 May 2011, at 12:00, Sebastian Bergmann wrote: On 05/15/2011 11:45 AM, Rasmus Lerdorf wrote: Let me know if there are any autoconf-related problems and we will get them tracked down. I am seeing the following warnings on Fedora 15 . Not sure this is a problem since the generated configure script works just fine. Same warning on OSX 10.6 with autoconf 2.68 (macports) However, configure and make work fine, too. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi: On 11 May 2011, at 23:10, Philip Olson wrote: On May 11, 2011, at 12:50 PM, Stas Malyshev wrote: The alpha release proposal by Andi contains the text: I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) +1 that would definitely demonstrate the ability to get moving again. An important sign to the larger community. However, the stability/instability of the feature set should be clearly defined. 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
Re: [PHP-DEV] 5.4 again
On 10 May 2011, at 12:04, Ferenc Kovacs wrote: performance problems, playing the bloated card, etc.), but they were overwhelmed by the positive feedback and the buzz about what can be further improved, etc. it seems that annotations lacked the critical mass when it was proposed. :( From my perspective, getting Traits in was also a lot of hard work with respect to the community. (Actually more then the technical details). While there seemed to be quite some buzz in the general PHP world, internals was rather uninterested in the beginning. The whole thing required a lot of, what I would characterize as, hand-holding. Internals is not the most open community and needs not only good arguments, but persistence. And, well, it also seem to require to get in touch with the right people... And now the whole discussion about 5.4 goes again in a direction where it will probably be stalled in the end. I am not to optimistic about an actual release date within 2011. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi: On 09 May 2011, at 09:50, Stas Malyshev wrote: I'm all for this idea, but the question is - can we have a good design implementation in next 2 months? If we can, great, if we can't - I'd rather have 5.4 than wait for it. E.g., if we have somebody ready to commit for certain timeframe to come up with it, then it makes sense to discuss it in this context. Can't we just draw this arbitrary line in the sand, and say from now on, controversial things are taken out and nothing new is added anymore? Everything which is not yet in trunk and is not required to round up the release should go into the release after 5.4? For me it seems there is no progress because there is still to much opportunity to improve things... So, instead of allowing to nominate new features, it might be best to stick to what we have now, and restrict ourselves to sort out the controversial stuff. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi: On 09 May 2011, at 19:25, guilhermebla...@gmail.com wrote: Are you sure? Please take a look at every topic defined on wiki page. Is there ANY topic to be discussed that came from userland? If you say yes, please point me to the thread. What I clearly see there is that every feature defined there came from users with php-src karma. Now I re-ask you, are you really sure it's only a small group that want something or do you now confirm that only php-src users have relevance on features request? Just for the sake of argument, a single counter-example can prove you wrong. And that counter-example is traits. I implemented the traits long before I got actual karma, and why do we have traits in trunk now? Because I kept arguing that they are useful, and that I as a user want them. Others liked the idea, and eventually I got the karma to push the code into the official repository. First it was developed completely outside of PHP and without asking anyone from internals, just because I wanted it... That is how open source works. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
Hi: On 19 Apr 2011, at 09:18, Stas Malyshev wrote: 2. Traits - I remember there was some unfinished business there? I am not aware of anything that could not be fixed before an alpha release. However, I would really appreciate if the community could commit to some release procedure and schedule. For me it is currently really hard to see what the next steps are. If a release manager gives me a deadline, I am sure that all the traits-related things can be finished. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor
Hi Sam: (becomes off-topic here, but for the sake of argument) On 19 Jan 2011, at 04:14, Sam Vilain wrote: On 19/01/11 10:50, Stefan Marr wrote: On 18 Jan 2011, at 22:16, Sam Vilain wrote: there doesn't seem to be an interpreter under the sun which has successfully pulled off threading with shared data. Could you explain what you mean with that statement? Sorry, but that's my topic, and the most well know interpreters that 'pulled off' threading with shared data are for Java. The interpreter I am working on is for manycore systems (running on a 64-core Tilera chip) and executes Smalltalk (https://github.com/smarr/RoarVM). You raise a very good point. My statement is too broad and should probably apply only to dynamic languages, executed on reference counted VMs. Look at some major ones - PHP, Python, Ruby, Perl, most JS engines - none of them actually thread properly. Ok, but the reason here is that building such VMs is inherently complex. And it has nothing to do with dynamic or not, with typed or what ever. The mentioned languages happen to be very successful in the domain of web applications, and as others already mentioned, the need for fine-grained shared-memory parallelism here is not clear. So, why don't we have Python without the GIL? Because nobody cared enough. However, there is still JRuby... Well, Perl's threading does run full speed, but actually copies every variable on the heap for each new thread, massively bloating the process. Cutting corners is the only way, if you do not have a great team of engineers. For the RoarVM we also have to cut more corners than we would like. So the question is why should this be so, if C++ and Java, even interpreted on a JVM, can do it? JVMs suffer from the same complexity. And C++, well, last time I checked there is just no threading model. There will be a memory model in C++0x, but there is nothing which makes it inherently hard to implement. Since you don't get any guarantees (beside the memory model semantics) and you don't have any GC either. In general, Java's basic types typically correspond with types that can be dealt with atomically by processors, or are small enough to be passed by value. This already makes things a lot easier. I don't think that buys you anything. Which basic types can be pass by copy? Ints, and bools perhaps. That takes a bit pressure from the GC, but does not really help with making things safe. Smalltalk does not know basic types. However, it knows an implementation technique called tagged pointers/tagged integers. This allows you to have 31-bit integers since pointer are aligned and do not need all bits. However, that really helps only with GC pressure. I've had another reason for the differences explained to me. I'm not sure I understand it fully enough to be able to re-explain it, but I'll try anyway. As I grasped the concept, the key to making VMs fully threadable with shared state, is to first allow reference addresses to change, such as via generational garbage collection. Hm, there is usually the wish that you can run your GC threads in parallel with mutator threads, here it is indeed helpful to support moving GCs. But how does it help with threads working in parallel on some shared object? Any point were an object is allowed to move requires synchronization. So, either someone has to change the pointer you own to that object, or you need an additional level of indirection. I guess you are talking here about having such an additional indirection, object handles? This allows you to have much clearer stack frames, perhaps even really stored on the thread-local/C stack, as opposed to most dynamic language interpreters which barely use the C stack at all. Why does having object handles give you a better stack frame layout? Using the C stack can be helpful for performance, well, makes other languages features harder to implement. For instance what about closures? Other techniques like recycling you stack-frame-objects is usually a simpler optimization without making it harder to stuff like closures. Then, when the long-lived objects are discovered at scope exit time they can be safely moved into the next memory pool, Ui ui ui. Slooow. I don't follow. Ok, there are things like escape analysis. And then there are techniques like on-stack-allocation. Both usually done in JIT compilers, not so much in interpreters. Are we still talking about interpreters? Or are you implying a incremental GC that is triggered on the return of method calls? as well as letting access to old objects be locked (or copied, in the case of Software Transactional Memory). There are to many things here discussed in a single sentence. Sorry, I am lost. Access to objects in your own frame can therefore be fast, and the number of locks that have to be held reduced. Ok, on-stack-allocation and biased locking? - memory allocation: object references' timeline
Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor
Hi Sam: I am following the discussion very interested, but just a question for clarification: On 18 Jan 2011, at 22:16, Sam Vilain wrote: there doesn't seem to be an interpreter under the sun which has successfully pulled off threading with shared data. Could you explain what you mean with that statement? Sorry, but that's my topic, and the most well know interpreters that 'pulled off' threading with shared data are for Java. The interpreter I am working on is for manycore systems (running on a 64-core Tilera chip) and executes Smalltalk (https://github.com/smarr/RoarVM). 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
On 06 Jan 2011, at 15:33, Johannes Schlüter wrote:
On Thu, 2011-01-06 at 14:38 +0100, Stefan Marr wrote:
On of those things is that you actually use ReflectionClass to reflect
on a trait.
That is really an implementation detail, and should be changed to not
confuse anyone on a conceptional level. We should not expose that kind
of engine/implementation detail.
This is the same with interfaces. What does class_exists('some_trait')
do? - I assume that returns true too.
It does return false for interfaces, that should be consistent and return false
for traits, too.
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi:
On 09 Jan 2011, at 17:23, Stefan Marr wrote:
This is the same with interfaces. What does class_exists('some_trait')
do? - I assume that returns true too.
It does return false for interfaces, that should be consistent and return
false for traits, too.
Ok, that is fixed and I added a trait_exists() to match the other functions.
Will add a note to the RFC.
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Jonathan:
Sorry, was not able to get back to those discussions earlier.
On 22 Dec 2010, at 16:39, Jonathan Bond-Caron wrote:
There are two remaining questions I have:
1) How do traits affect the reflection API?
Johannes implemented some features in the Reflection API.
However, they are very ad-hoc, and there are some points which could be
designed differently to make the concepts more clear.
On of those things is that you actually use ReflectionClass to reflect on a
trait.
That is really an implementation detail, and should be changed to not confuse
anyone on a conceptional level. We should not expose that kind of
engine/implementation detail.
Thus, there remains stuff to be done about reflection. In general, I would like
to be able to access all information that was in the source code. However, time
constraints are an issue for me. If there would be a new release date for an
alpha or something, I think I could get some time to work on it...
2) Do we want to be able to declare trait requirements for properties and
methods? If so what syntax?
Well, there was the proposal to use require to express constraints for the
composing class, which is something I liked.
However, I would not go to support properties, too, since I still maintain the
opinion that we do not actually do something about state with regard to traits.
A note on the syntax proposed by Nathan:
trait require Foo
An option could be:
trait Foo {
require {
public $var;
function ratio();
}
Hm, well, we already got abstract methods for the methods part.
trait Bar {
require interface Iterator;
}
And expressing the requirement for an interface or an abstract class seems to
be the only thing missing, I think.
However, I would not put that in the body but into the hat.
trait Bar require OneSpecificClass, AndPossiblyAnInterface,
OrPossiblyAnotherInterface {}
The idea comes from:
http://code.google.com/p/es-lab/wiki/Traits
I found this trying to look for alternative keyword for 'require'.
Yes, Tom worked on that a while ago, but it was to easy to implement it in a
library for JavaScript. To easy to be considered for a language feature...
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Larry: On 21 Dec 2010, at 03:24, Larry Garfield wrote: I don't believe the RFC mentions how those resolve in case of collision, though. If two traits define the same abstract method, does that cause a collision that needs manual resolution or can the using class just define it once and thereby support both traits? Abstract methods do not cause collisions, no. So, there can be an arbitrary number of traits asking for an abstract method with identical name, and the only thing that has to happen is that it is implemented eventually, perhaps by another trait. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extensions to traits
, the traits mechanism should be extended to allow
more desirable behaviours to be programmed.
Warnings
- - - -
To avoid silent unintended shadowing, I suggest issuing a warning when a
conflict between trait and class methods occurs. So this would trigger
a warning:
trait SaySomething {
public function sayIt() {
echo Something\n;
}
}
class Sayer {
use SaySomething;
public function sayIt() {
echo Hello world!\n;
}
}
Ok, well, we could see the actual class body as another trait, and require it
to follow the same composition rules, and that way make require the programmer
to use insteadof in such a case.
In return that would mean, that traits are not part of the inheritance chain at
all anymore.
Thus, first is the inheritance chain used to build up the implementation of a
class, and afterwards all the traits are composed, while the original class is
seen as another trait.
That idea has certainly something to it.
use SaySomething {
sayIt = null;
}
use SaySomething {
unset sayIt;
}
use SaySomething {
sayIt = SaySomething::sayIt;
}
I would reject that based on the arguments from the beginning of the email.
Ok, thats enough for this email.
I will come back to the extension in a later email.
Thanks for the proposals
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
Re: [PHP-DEV] Extensions to traits
Hi Ben: Here the second part, on your extension proposal. On 02 Jan 2011, at 13:16, Ben Schmidt wrote: Extension - - - - - I suggest these two problems can be simply solved by introducing two additional uses of the trait keyword: as a scoping keyword and an access specifier. As a scoping keyword, it would be used analogously to self. Method calls such as $this-print() could be replaced with trait::print() when the programmer desires to ensure that their trait method, and only their trait method, is called--when there is no intention that overriding should be possible. It would only be able to be used in a trait, and could only be used to reference methods or properties defined in the same trait, using their original name. As an access specifier, it would be used instead of public, private, etc. in trait definitions, to mean that the member (data or method) can and can only be accessed using the mechanism above (trait::). Ok, that would actually get us around all the meta-programming problems. When you say that the 'trait'-access modifier always requires the access via a specific keyword (trait::) then mangling the name should be possible. On the other hand, what would iterating over the object properties show? Multiple properties with the same name, like with inherited private properties I suppose? And an occurrence of trait:: would mean, do a $this- but mangle the name first with the trait's name the original definition was in. Should be possible, but would certainly impact the Zend Engine a bit more than what we have now. Certainly an interesting approach. Has someone else an opinion on that? Overriding == Limitation -- At present, the overriding semantics of traits are that a method defined in a class proper overrides a method defined in a used trait which in turn overrides a method defined in an ancestor class. Bye the way, where comes that terminology from: class proper? We are talking about the body of a class, right? Well, but I will stop here, and try to cover the rest in the next mail... 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extensions to traits
;
if ($current_values!=trait::$original_values) return false;
return prev::save();
}
}
trait UsingHashesForIDs {
public function save() {
if ($this-id===null) $this-id=random_hash();
return prev::save();
}
}
class SessionRecord extends ActiveRecord {
protected static $default_values=array(
'user'='',
'time'=''
);
use UsingHashesForIDs;
}
class Client extends ActiveRecord {
protected static $default_values=array(
'user'='',
'name'='',
'address'=''
);
use EnsuringNoConcurrentChanges, LoggingOperations {
save = EnsuringNoConcurrentChanges::save,
LoggingOperations::save;
}
}
Ok, that example is, well, not actually helping you.
You can do all the things here without your extensions, I believe.
Your problem with the save methods is solved by aliases and parent:: (parent::
only has semantics with respect to inheritance, so it will do the right thing.
Your Client will have a save method that calls the aliased versions of the
saves in the order you want.
And in get() you can also just use parent::, no?
The only problem with aliases is that you do not get self-recursion, but you do
not use that here.
Final note regarding grafts
===
Grafts are dead. There is no implementation, and I do see traits and grafts as
an either the one or the other, but not both. We do not need to make PHP more
complex...
All in all, I would like to have all the proposals recorded somewhere, in a way
easily findable when you look up traits RFCs. Should be possible to group them
in a namespace on the wiki, right?
Thanks again and sorry for 'rejecting' most of your ideas, but thats not final,
I am still open for arguments.
By breaking up the topics into subthreads, it hopefully makes it easier for the
community to comment on the different topics, too.
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Ben: On 03 Jan 2011, at 06:58, Ben Schmidt wrote: I'm a latecomer here, but... Stefan, doesn't this conflict with what you've written here (and the test cases in SVN)?: http://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Or is what is happening here that the properties in traits are treated essentially as declarations rather than definitions, triggering errors but not actually creating properties, and you think they should actually create properties? Sorry, I do not understand. Is the text in the RFC contradicting or not clear enough about what the test cases show? The intention was to provide the developer with hints when it is possible that state is incompatible. Until now, the reason why there is not fancy mechanism for conflict resolution for properties in traits is, first, the dynamic nature of PHP which makes certain things like 'renaming' inconsistent with the rest of the language, especially its meta-programming facilities, and second, the added problem with state, that you actually have many usecases where the state needs to be merged. However, merging behavior is not possible, which simplifies the language constructs for handling behavioral conflicts. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Ben: On 03 Jan 2011, at 10:35, Ben Schmidt wrote: OK. So this comment from your email is outdated?: Yes, outdated since this email: http://marc.info/?l=php-internalsm=129288735205036w=2 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Larry: On 20 Dec 2010, at 17:04, la...@garfieldtech.com wrote: Perhaps if both traits use the same variable name, visibility, *and* default value then there is no error? There is not fatal error, however, currently there is E_STRICT notice. I suspect this issue dovetails with the Traits-and-interfaces thread from earlier. Ehm, not sure what you want to get at. The idea of expressing that the composing class needs to satisfy an interface, or perhaps inherit from a specific class still seems to have a number of valid use cases. However, there was a single strong opinion against it, as far as I remember. Anyway, on the topic of properties. For the records, I updated the RFC with the following section. http://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Comments are welcome. Thanks Stefan = Handling of Properties/State = Traits do not provide any provisioning for handling state. They are meant to provide a light-weight mechanism for flexible code reuse, with the mean goal being to avoid code duplication. Moreover, should not be confused with typical use cases of classes. When a strong coherence/coupling between methods and state is required, and certain invariants have to be maintained on the state, this is a good indication that a class is the right abstraction to implement that problem with. However, every behavior needs state to operate on, otherwise it could be just a static functional helper method. Thus, trait code will either need to use accessors, which is favorite way to go since it provides full traits semantics, or they use properties, which is possible but rather a convenience feature. Since state is a complex problem, and the knowledge about compatibility of state form different traits is only present in a concrete composition, proper state handling would need language features which are currently considered beyond the scope of what is necessary for PHP. (See [[http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf|Bergel et al]]) Thus, the goal for a consistent language design is to raise awareness of the problem, promote the use of accessors, and break early in case the changes to a trait is potentially problematic for a class using it. This results in the following rules: - Properties are considered incompatible if they differ in their definition. This means, they differ in the applied modifiers (static, public, protected, private) or their initial value. - Incompatible properties result in a fatal error. - In all other cases, i.e., when the definitions are identical, an E_STRICT notice is shown to raise awareness about the potentially problematic, and discouraged use of properties. - For those checks, all properties are treated equal. Properties from the base class and the composing class have to be compatible with properties from traits as well as the properties between all traits have to be compatible. - Non-coliding properties, and properties which are not considered incompatible behave exactly the same as if they would have been defined in the composing class. This property handling was implemented in [[http://svn.php.net/viewvc?view=revisionrevision=306476|SVN revision 306476]] and examples are given in the test cases. --Larry Garfield -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Matthew: On 19 Dec 2010, at 17:22, Matthew Weier O'Phinney wrote: Exactly. I wouldn't default to public on conflicts, though -- just with the highest declared visibility (e.g., if one trait defines as private and the other as protected, protected wins). I am currently actually implementing the most restricted proposal: all differences in the property definition will lead to a fatal error. The reasoning behind this is, that the semantics of state is not predictable and all changes in the class/traits hierarchies which are incompatible should give the developer an immediate feedback, i.e., make potentially incompatible code break. That is not the most 'dynamic' of all possible solutions but seems to fit with the rest of PHP. What I have in mind is also not how the methods integrate into the inheritance chain, thus, a property in the body of the class does not override all property definitions in traits (this is the case for methods). I think that will be useful for the very same reason. And well, I hope an educative error message will steer the crowed in the right direction to use accessors. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Larry:
On 16 Dec 2010, at 23:31, Larry Garfield wrote:
I am fine with this approach, with 2 caveats:
- If you actually do want to make two traits use the same property, it looks
like the answer here is Either have no property and demand the existence of
an accessor that returns by reference, or you can't write E_NOTICE-safe
code. Is that true?
Yes, that is the tradeoff, perhaps the notice could be restricted be shown in
strict-mode only.
The manual says the following about E_STRICT, so it seems to fit, but I am not
sure about the usual usage of E_STRICT throughout the engine.
Manual:
Note:
In PHP 5 a new error level E_STRICT is available. As E_STRICT is not included
within E_ALL you have to explicitly enable this kind of error level. Enabling
E_STRICT during development has some benefits. STRICT messages will help you
to use the latest and greatest suggested method of coding, for example warn
you about using deprecated functions.
- When the visibility collides, should we be folding to the most restrictive
or least restrictive? I'm not sure myself; I'm more interested in your
reasoning for going for most-restrictive.
So, in general, I think, there is no 'right thing' to do here, because the
definitions seem to be incompatible but that is only decidable at the
application-level.
There is another, related, edge-case in the test case below.
In the test we have different initial values for the properties, which makes it
'obvious' that they are incompatible.
Thus, in that case I would argue for a E_COMPILE_ERROR instead of a notice.
The reason to use the stricter modifier is, well, arbitrary.
At least I do not find an argument for either way that completely convinces me.
At the moment, the main reason is that 'public' can be considered to be the
default visibility modifier.
Based on the semantics of 'var' and dynamic properties.
Thus, private tends to imply that an additional constraint was consciously
applied to the property, which should be preserved.
Well, but as I said, thats kind of arbitrary and if you look at the inheritance
rules and try to reason from the view of clients with respect to the external
interface, then going with public as the chosen modifier also starts to sound
reasonable...
--TEST--
Conflicting properties with different visibility modifiers should be merged
to the most restrictive modifier.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $hello = foo;
}
trait THello2 {
public $hello = bar;
}
class TraitsTest {
use THello1;
use THello2;
public function getHello() {
return $this-hello;
}
}
$t = new TraitsTest;
?
--EXPECTF--
Fatal error: Conflicting definitions for property TraitsTest::$hello provided
by THello1, THello2 in %s on line %d
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Jonathan: On 18 Dec 2010, at 18:14, Jonathan Bond-Caron wrote: Does the order of the declaration matter? No, the order does not matter, and that is one of the key points of traits compared to mixins or Python's way of multiple inheritance. So, any kind of order-dependent solution would be inconsistent with the design of traits. though I'd be happy with simply E_FATAL until people start using traits What do you mean by the second part? (until people start using traits) Changing the design retrospectively does not seem to be the best option? 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi:
From my point of view the right thing to do with regard to properties is
defined in the test cases below.
The rational behind providing this semantics is based on the fact that PHP
allows to define properties dynamically anyway, so there is no way around
properties.
However, there should be a way that a developer can notice that the code might
not behave as expected in the composed class.
It is true that behavior needs state to operate on, however, accessors are a
common pattern and fully supported by traits. Furthermore, traits are not
supposed to replace classes, and when a trait does more than just providing
code that is to be easily reused, then the designed should ask the question
whether that is not actually a class, which then provides the necessary
guarantees to enforce the invariances the code expects.
Thus, I would like to keep traits as a lightweight concept for code reuse.
Best regards
Stefan
--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $foo;
}
trait THello2 {
private $foo;
}
class TraitsTest {
use THello1;
use THello2;
}
var_dump(property_exists('TraitsTest', 'foo'));
?
--EXPECTF--
Notice: Trait THello1 and THello2 define the same property in the composition
of TraitsTest. This might be incompatible, to improve maintainability consider
using accessor methods instead. Class was composed in %s on line %d.
bool(true)
--TEST--
Non-conflicting properties should work just fine.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $hello = hello;
}
trait THello2 {
private $world = World!;
}
class TraitsTest {
use THello1;
use THello2;
function test() {
echo $this-hello . ' ' . $this-world;
}
}
var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));
$t = new TraitsTest;
$t-test();
?
--EXPECTF--
bool(true)
bool(true)
hello World!
--TEST--
Conflicting properties with different visibility modifiers should be merged
to the most restrictive modifier.
--FILE--
?php
error_reporting(E_ALL);
trait THello1 {
public $hello;
}
trait THello2 {
private $hello;
}
class TraitsTest {
use THello1;
use THello2;
}
$t = new TraitsTest;
$t-hello = foo;
?
--EXPECTF--
Fatal error: Cannot access private property TraitsTest::$foo in %s on line %d
On 11 Dec 2010, at 17:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property
names.
The current solution/idiom for handling state safely in a trait is to use
either abstract set/get methods or an abstract get that returns a reference
to the property in the class.
However, at the moment it is possible to define properties in a trait:
trait Foo {
private $a;
public $foo;
}
For the moment, that information is completely ignored, thus:
class Bar {
use Foo;
}
property_exists('Bar', 'a') === false
Well, and that is a rather inconsistent status-quo.
I would like to have that fixed in one or another way.
One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about
properties, however, the dynamic property creation is still possible.
Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge
public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice?
Options here are a notice whenever a property is defined in a trait, or
whenever properties are silently merged.
Comments very welcome.
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 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
Re: [PHP-DEV] Traits and Properties
Hi Richard:
On 13 Dec 2010, at 14:13, Richard Quadling wrote:
From the rfc [1], A Trait is similar to a class, but only intended to
group functionality.
I'm guessing that says it all. A trait has no properties.
It is really a practical concern of language consistency for the moment.
I am not talking about any fancy new language feature to handle state.
At the moment, I am just concerned with examples like the following:
trait Foo {
function bar() {
$this-baz = 'abcd';
}
}
If that example becomes more complex, I would consider it to be good software
engineering practice to document the usage of $this-baz and its semantic.
For classes this is usually done by explicitly naming the property in the class
body.
At the moment, there is nothing which hinders you in doing that for a trait.
However, since traits do not provide any safety provisioning for state, i.e.,
there is no collision handling for properties, the question is, how do we
either promote to use explicit accessors or how do we deal with the inevitable
and certainly justified use of properties in one or the other way.
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Richard: On 13 Dec 2010, at 14:31, Richard Quadling wrote: On 11 December 2010 23:31, Stefan Marr p...@stefan-marr.de wrote: The current status of the property behavior is not yet documented explicitly On the assumption that traits WILL include properties (with visibility) and aliasing can do all its magic, how would the situation be handled where multiple traits define shared properties. I've not got a use case, but say trait1 and trait2 both define the same property. Assuming name conflicts are handled via aliasing, then the property needs to alert the aliasing code that this property is a non conflicting property. Just to emphasize this another time: aliasing is no magic, it is NOT renaming. (And it is only supported for methods.) The important implication here is, that aliasing is only useful from the viewpoint of the composing class. Form the trait's perspective, aliasing does not have any effect. Aliasing can be used to make a function accessible that has a naming conflict with another function. It enables composition of traits, but does not do anything with regard which function names a trait-function calls. In PHP all function names are late bound, there is no inner binding between functions in traits. Hope that clarifies what I perceived as a misconception. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi Nathan:
On 11 Dec 2010, at 19:35, Nathan Nobbe wrote:
Regarding visibility modifiers, why not carry them over from the trait
directly, private in the trait definition results in private in the class
definition.
The problem will be hopefully more clear in the following example:
trait StateMachineDoor {
private $currentState;
public function open() {}
}
trait StateMachineElevator {
public $currentState;
public function callElevator() { ... }
}
These two traits are not compatible since currentState has different semantics
in both traits.
With the current design of traits, there is no language solution to this
problem.
The suggestions to avoid the problem are to use better names like
$currentDoorState and $currentElevatorState, or to rely on accessors which is
currently the only variant in which the programmer will notice that there is an
incompatibility:
trait StateMachineDoor {
abstract function getCurrentState();
public function open() {}
}
trait StateMachineElevator {
abstract function getCurrentState();
public function callElevator() { ... }
}
However, you might have a different situation, one where the traits are
composable with respect to their state, i.e., they need to work on the same
state:
trait OutputIterator {
public $array; // not sure why that is public here, but the implementor
chose to make it public...
public function printNext() {...}
}
trait SortArray {
private $array; // this developer chose to make the array private, for what
ever reason...
public function doSort() { ... }
}
I hope that makes the possible situations clear: state can either be composable
or not, that really depends
on the trait. And there is no language solution for it build in at the moment.
So, back to my original question:
class SomethingOutputableAndSortable {
use OutoutIterator, SortArray;
}
What is the visibility of $array supposed to be in this class? private or
public?
And further, in the very first example of this mail, ideally there should be
some warning, however, that warning would be annoying for the last example,
since here the state does not collide...
Best regards
Stefan
PS: there has been discussion on stateful traits before, but the language
solutions to that where considered to complex.
--
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
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
Hi:
I added the proposal to the RFC.
See
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_implement_interface
= Requiring Composing Class to Implement Interface =
Traits are able to express required methods by using abstract method
declarations.
An abstract method can be satisfied in varios ways, for instance by
implementing it
in the composing class or by bringing it in from another Trait.
However, for traits that require complex interfaces to be satisfied, this
approach is tedious
and fragile, since it requires the developer to state all used methods
explicitly.
Another solution is that a Trait expresses a requirement for the composing
class to implement
a certain interface. This is not entirely identical to using abstract methods,
however.
First, it imposes a requirement on interface level and thus will have the same
fragility
with respect to interface changes as all other clients of an interface.
On the other hand, it avoids duplications of abstract method definitions and
makes
the interface the main entity of responsibility as for normal client-interface
uses
in current code.
?php
// IteratorUser works with $this using the Iterator interface
trait IteratorUser require Iterator {
function foo() {
$next = $this-next();
...
}
}
// composed into a class that needs to implement the interface
class Example implements Iterator {
use IteratorUser;
}
Are there any objections to implementing this?
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
Re: [PHP-DEV] Traits and Properties
Hi Pierre:
On 11 Dec 2010, at 23:13, Pierre Joye wrote:
hi,
Would it be possible to somehow document what you are discussing here?
It is not too easy to keep track of all discussions about traits
(along other things). Maybe in draft RFC or a simple page in the wiki.
Doing so will help to have a quick view about the open questions or
recent changes/propositions.
Yes, I try to keep track of all this in the RFC:
http://wiki.php.net/rfc/horizontalreuse?do=revisions
The current status of the property behavior is not yet documented explicitly,
it is only implied since it is not handled at all...
And, it is the only open question that 'needs' to be solved since it is an
inconsistency.
For instance the 'require Interface' is more like an additional feature.
Best regards
Stefan
Thanks!
On Sat, Dec 11, 2010 at 5:47 PM, Stefan Marr p...@stefan-marr.de wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property
names.
The current solution/idiom for handling state safely in a trait is to use
either abstract set/get methods or an abstract get that returns a reference
to the property in the class.
However, at the moment it is possible to define properties in a trait:
trait Foo {
private $a;
public $foo;
}
For the moment, that information is completely ignored, thus:
class Bar {
use Foo;
}
property_exists('Bar', 'a') === false
Well, and that is a rather inconsistent status-quo.
I would like to have that fixed in one or another way.
One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about
properties, however, the dynamic property creation is still possible.
Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge
public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice?
Options here are a notice whenever a property is defined in a trait, or
whenever properties are silently merged.
Comments very welcome.
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
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
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
Re: [PHP-DEV] Traits and Properties
Hi Sebastian: On 11 Dec 2010, at 19:36, Sebastian Bergmann wrote: And, to discorage users to go this way, should there be a STRICT notice? If you want to discourage attribute declaration in a trait, don't allow it at all. Not allowing it is not an option as far as I can tell. You can always use dynamically defined properties in a method. Changing that would change the whole character of PHP. Then we would have two types of methods, methods that are defined in the class directly and can do what ever they want with properties, and methods from traits which are restricted and can't access any state. I think, that would be to much penalty for all the valid use cases where a naive property usage in a trait is still just fine. Best regards Stefan -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
Hi Nathan:
On 10 Dec 2010, at 17:49, Nathan Nobbe wrote:
Def not :D, however, I still think this paradigm is lacking. Don't you think
it makes more sense if I write a trait that expects a given interface or
class to be able to specify said interface/class in it's entirety with just a
single identifier rather than listing out all the methods?
For example, I think this would be ugly
?php
trait IteratorHelper{
abstract public current();
abstract public key();
abstract public next();
abstract public rewind();
abstract public valid();
}
?
essentially you're redeclaring the entire interface in the trait, the same
would be true of the public interface of an expected class. i think it would
be much more elegant to allow a specification on the trait declaration
itself, something like
?php
trait IteratorHelper expects Iterator {
...
}
?
:D That was exactly my thought when I was writing my first answer.
My second thought was, damn, not another keyword...
But since you also seem to see the need, we should give it a thought.
Anyone else with an opinion on that?
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
Hello Martin: On 10 Dec 2010, at 18:15, Martin Wernstahl wrote: First i have to say that I am not a PHP internals developer, but as a user I think it would maybe be better to just let the trait use the implements keyword, and copy that to the classes utilizing the trait? Or does that seem illogical when the trait does not implement all of the methods specified by the interface? Implements sounds misleading to me. Read: trait Foo implements Bar. Sounds like Foo is providing Bar and not expecting the interface to be there. But require might be a good keyword to be reused. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
Hi Nathan:
On 09 Dec 2010, at 23:42, Nathan Nobbe wrote:
What I'm getting at is the scenario when a trait is designed to be used in
concert with the class in which it is being used. In this case the trait
expects certain functions to be available on the class in which it is used
with. If the methods aren't there (or checked for at runtime) a fatal error
is raised.
A quick example
?php
class A {
use AHelper;
function blah() {}
}
trait AHelper {
function meh() {
// hoping we get used w/ instances of A ...
return $this-blah() * 5;
}
}
class B {
use AHelper;
/// waiting for a runtime error if blah() is ever called ..
}
?
Do you see what I mean?
No, do not really see what you are getting at.
How is your approach using the instanceof checks (from the first mail)
different from changing AHelper to require blah() by stating this requirement
using an abstract method definition?
For the trait it is not important where that method is implemented, it just has
to be in the final composed class.
So, why don't you want the following trait?
trait AHelper {
abstract function blah();
function meh() {
// hoping we get used w/ instances of A ...
return $this-blah() * 5;
}
}
You want to avoid the fatal error during runtime, right?
Do you prefer dynamic checks over compile time checks?
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Conflicts: Collisions as Warnings or Fatal?
Hi: On 05 Dec 2010, at 15:53, Benjamin Eberlei wrote: I wondered before why this only triggers a warning. A fatal error sounds good at that point in my opinion. It is comparable to interfaces/Abstract classes being implemented wrong and this also leads to a fatal error. Additionally there is no way this just happens to your code. You have to make changes to a trait explicitly to trigger this problem, so this is only happening in development. So, that is the way to go? The original idea to go with a warning was, that it is not the case that the engine is in an unrecoverable state, thus, the code actually will work in that case, but perhaps produce unexpected results. In general, PHP uses fatals far to often for my taste, but well, to keep it consistent, we can go fatal here, too. Is there a general consensus on that? 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
[PHP-DEV] Traits and Conflicts: Collisions as Warnings or Fatal?
Hi: While preparing some explanations on how to use traits, I stumbled over an inconsistency in the current implementation. Currently collisions, if they are explicit in the code, lead to a warning and are resolved by explicit exclusion of the two methods that collide[1]. However, there are other ways to provoke a collision, for instance by introducing a new alias during composition[2]. [1] http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/error_015.phpt?revision=305512view=markup [2] http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/language010.phpt?revision=305512view=markup Collisions usually point to implementations that changed unexpectedly, and the implicit resolution might be problematic since it could hide the real cause for a bug. So, should that warning be changed to a fatal error, or should the other fatals be warnings, too? 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi: On 01 Dec 2010, at 01:31, presid...@basnetworks.net wrote: That is true for PHP variables. isset is basically saying does this variable exist, and unset is saying to get rid of it. This is also true for object properties - see magic methods. I don't see why you shouldn't be able to unset them - you can do that with regular properties... So what you imagine would happen if you call unset($foo-property) or isset($foo-property)? Its not a matter of consistency - Properties, as a cross-language concept are not meant to work that way. I tend to disagree. The need to be consistent inside of PHP has precedence over being consistent with other languages. You need to think of a property as a set of two methods that just have a pretty syntax. Methods cannot be unset, and nor should properties be allowed to. isset() should simply tell us whether a property with the specified name is part of the class or not. I think, it really is the other way around. Properties are meant to give the programmer the illusion that she is just having a field. That is abstraction. She does not care about implementation details. And that is the power of properties. isset() and unset() are perfectly fine in that context. And I do not see a problem to provide the standard semantics for them automatically, and let the programmer add isset/unset methods to the property as needed in exactly the same style as get/set. There is a good usecase for asking whether a property has been set, for instance to verify initialization. And, of course unset has also a useful meaning. It is about the value, and even so there are methods around a value, properties are meant to be values. There are definitely use-cases where that does not hold, but that is application specific. isset() in the way you suggest would just be confusing. It would allow is to say that a property does not exist, when in fact it does exist. This is not logical. From the docu: isset — Determine if a variable is set and is not NULL There is nothing confusing about isset($this-Hours) == FALSE in your example if isset($this-seconds) == FALSE. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi Richard: On 01 Dec 2010, at 10:57, Richard Quadling wrote: If we think of properties as this new entity for the language (rather than somehow massaging existing entities to fit a new usage scenario), then isset($instance-property) will always return true for any defined property. Even if the getter would return null. This is new behaviour and can be easily documented. isset() for a property is more like method_exists() than isset() on a variable. I tend to see that rather different. Properties are not about methods, properties as in C# are about abstracting from the actual realization of how the state is represented internally that is exposed by a property. Thus, properties like proposed here should be used to provide the illusion of having normal class variables. And in that scenario it makes sense to talk about the value the property represents and not the fact that there are methods. So, from my point of view isset/unset have perfectly valid semantics on many of the usual cases. Even so, I agree, there are cases where that is not so, but in those cases isset/unset could be specialize like set/get. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 01 Dec 2010, at 14:10, presid...@basnetworks.net wrote: Unfortunately I find that to be one of the major downfalls of PHP. It sometimes disregards defacto standards that are set across the entire industry, which causes a lot of frustration for new programmers. Sometimes the functionality PHP adds by going its own way is worth it, but often it is just a confusing mess. Thats just my opinion though, YMMV. Still, if it is not consistent in itself it is worse than not following certain designs which make sense for other languages only. isset() in the way you suggest would just be confusing. It would allow is to say that a property does not exist, when in fact it does exist. This is not logical. From the docu: isset — Determine if a variable is set and is not NULL There is nothing confusing about isset($this-Hours) == FALSE in your example if isset($this-seconds) == FALSE. Right, I understand how it would work, and the reasons why it would make sense, but it just feels wrong to me. When you unset() a variable in a class, that whole variable is gone. Its not just hiding somewhere, its completely gone. If a property were to pretend it is not set, with an isset method, it would still be there - just hiding. That is why it does not make sense to me. The main problem here is that unset and isset are not symmetric. isset() basically means there is a value. Where unset() destroys the _holder_ of the value. In that sense, unset is special since it works on another level, on the same level as property_exists(). There are several possible approaches, but the main point here is that at least isset() still makes sense. property_exists() and unset() should be dealt with carefully in another way. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi: On 30 Nov 2010, at 14:42, presid...@basnetworks.net wrote: However, it does make sense to be able to define a property as part of a trait, as again, it is basically just a pair of methods. When I get some time, I will try to add a syntax for traits to the RFC. The only thing really necessary for that would be a specification on how to name/to refer to the getter/setter to be able to handle the conflicts. The rest should work out of the box. As far as I can see from the proposal. Best regards Stefna - Dennis -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
Hi: On 23 Nov 2010, at 02:30, Felipe Pena wrote: - Traits may not be ready yet for pre-release - see http://svn.php.net/viewvc?view=revisionrevision=298348 The listed todos where: - Reflection API That was implemented by Johannes as far as I remember. - support for traits for internal classes - currently destroy_zend_class does not handle that case For support of internal classes was no clear interest yet, so it never got done. Is that a show stopper? 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
Re: [PHP-DEV] Traits and static methods
Hi Simas:
On 22 Nov 2010, at 13:47, Simas Toleikis wrote:
Would it work if instance is saved inside a local static var like:
public static function getInstance() {
static $instance = NULL;
if (is_null($instance)) {
$instance = new self();
}
return $instance;
}
http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/language013.phpt?revision=300283view=markup
The test case says it works ;)
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trait behavior when providing a new name while no conflict exists
Hi Patrick:
On 18 Nov 2010, at 16:01, Patrick ALLAERT wrote:
Hi,
Is this intended not being able to give a new name to a method even in
case of no conflict?
In the following example, I try to provide the name sayIt
additionally to saySomething from trait Hello:
?php
trait Hello {
public function saySomething() {
echo 'Hello';
}
}
class MyHello{
use Hello {
Hello::saySomething as sayIt;
}
}
?
Thanks for catching this, it is a bug.
It works without the Hello:: part and it should also work with the Hello::.
Fixed with the following commit:
http://svn.php.net/viewvc?view=revisionrevision=305512
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
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Another question on traits
Hi Nathan:
On 17 Nov 2010, at 19:06, Nathan Nobbe wrote:
So it sounds like implementing an interface directly with a trait has been
shot down,
Yes, Traits are meant to be compile-time only, they are not used to introduce
typing relationships.
what I wonder about is will it still work if a class implements
an interface and uses a trait which provides the functions in said
interface?
Yes, sure.
?php
interface IHello {
public function sayHello();
}
trait SayHello {
public function sayHello() {
echo 'hello world';
}
}
This is a typical pattern I would expect to see in code that uses traits.
You have an interface and then you provide a trait thats provide a standard
implementation for that interface. I would probably call the trait similar to
the interface HelloImpl or THello or so.
class MyHelloWorld implements IHello {
use SayHello;
}
$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool (true)
?
If that does not work, it is a bug I think.
Best regards
Stefan
thx,
-nathan
--
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
Re: [PHP-DEV] Traits and static methods
Hi Simas: Thanks for sending me the test cases. I checked them in, and surprise surprise: it actually was already completely implemented. I didn't had to touch any code... So the missing bit was being more explicit in the RFC. I added a section and an example based on your Singleton code. Now I also remember what the reference to the static modifier was about. You cannot use it to change it for a standard method. That means, if you have a normal method, you cannot make it static however, you can for instance make a public method private, or add an alias for it. That was what that statement was referring to. http://wiki.php.net/rfc/horizontalreuse Hope that helps Best regards Stefan On 17 Nov 2010, at 08:55, Stefan Marr wrote: Hi Simas: On 17 Nov 2010, at 07:32, Simas Toleikis wrote: Alright then, I am sure someone will find more uses for static methods in Traits like factories/utilities (especially if traits can be made to work with late static binding). I assume this will be implemented in one way or another before or after first 5.4 alphas! :) Send me the tests/phpt-files for it, and I will have a lock at it over the weekend. 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 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and static methods
Hi Simas: On 16 Nov 2010, at 18:46, Simas Toleikis wrote: The first thing that comes to my mind is a Singleton implementation - this is where I found myself literally copying most of the code in the past. As far as I know there is no way to implement this pattern properly in PHP without duplicate code (due to lack of multiple inheritance/templating). Unfortunately, the same RFC document mentions this for trait methods: The static modifier is not supported, because it would change the methods semantics and references to $this would break. .. and that pretty much defeats Singleton-Trait implementation. Is there any particular technical/design reasons why traits can't handle $this inside static methods just like regular static methods do (with a fatal error)? Hm, good question. I don't recall any implementation details. Haven't touched the code for too long. From the top of my head, I don't see why it should not work. If I would have elaborated a bit more what I was thinking when I wrote that comment... Following the motto 'it is just compiler assisted copy and paste' I think it should be implemented. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and static methods
Hi Simas: On 17 Nov 2010, at 07:32, Simas Toleikis wrote: Alright then, I am sure someone will find more uses for static methods in Traits like factories/utilities (especially if traits can be made to work with late static binding). I assume this will be implemented in one way or another before or after first 5.4 alphas! :) Send me the tests/phpt-files for it, and I will have a lock at it over the weekend. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GPU Acceleration
Hi: On 12 Nov 2010, at 16:35, Scott MacVicar wrote: Do you have a patch for this? The only thing stopping it is no one had written it. So, I'd thank you for *constructive* answers. *sigh* He was asking for constructive answers. Kenan, I guess the most viable approach to go in such a direction is to look at something like HipHop[1] or any other PHP compilation approach. The problem is to find an appropriate workload for the GPU. There is high overhead involved in starting up code on a GPU and typical PHP workloads aren't a good match at all. At least if you stay in the Web app/DB-bound application area. Best regards Stefan [1] https://github.com/facebook/hiphop-php [2] http://www.phpcompiler.org/ -- 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
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
Hi Tom: The status is still identical to what the RFC says + some extensions to the reflection API. Thus, you can define properties in Traits just like in classes, and I would encourage you to do so, if that is the way you use PHP. However, there is no conflict detection with other traits. Thus, you have to make sure that your property names are descriptive and unique over all traits you combine. Finding a solution for that problem wasn't possible so far. At least not in a way that makes people happy i.e. avoids tons of complex and rather academic constructs to ensure that you get what you want with respect to state. Hope that helps Best regards Stefan On 27 Aug 2010, at 16:43, Tom Boutell wrote: What was the status of data for traits in the implementation that went into trunk? Would one have to do that by creating public properties that aren't formally defined? On Fri, Jun 4, 2010 at 8:13 AM, Christian Kaps christian.k...@mohiva.com wrote: That sounds good and I hope it will be included in the next release. Best regards, Christian Hi: On 04 Jun 2010, at 13:46, Christian Kaps wrote: A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? The code is committed to trunk, and thanks to the community there have already been some improvements and fixes for corner cases. We even got some basic reflection capabilities, too. So, it is there. Now it is just a matter of defining a release and either including it or not... Best regards Stefan PS: Snapshots are here http://snaps.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Traits and static variables
Hi:
Was just thinking about some details of the traits implementation.
From my perspective, static variables in methods should work like the method
would have been actually implemented in the class using the traits. Thus,
static variables should be independent for the different traits usages.
Any thoughts on that?
Below, I attached the relevant test case.
Best regards
Stefan
--TEST--
Statics work like expected for language-based copy'n'paste. No link between
methods from the same trait.
--FILE--
?php
error_reporting(E_ALL);
trait Counter {
public function inc() {
static $c = 0;
$c = $c + 1;
echo $c\n;
}
}
class C1 {
use Counter;
}
class C2 {
use Counter;
}
$o = new C1();
$o-inc();
$o-inc();
$p = new C2();
$p-inc();
$p-inc();
?
--EXPECTF--
1
2
1
2
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
Hi: On 04 Jun 2010, at 13:46, Christian Kaps wrote: A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? The code is committed to trunk, and thanks to the community there have already been some improvements and fixes for corner cases. We even got some basic reflection capabilities, too. So, it is there. Now it is just a matter of defining a release and either including it or not... Best regards Stefan PS: Snapshots are here http://snaps.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/trunk/ UPGRADING Zend/zend_builtin_functions.c
On 07 May 2010, at 10:34, Sebastian Bergmann wrote: On 05/06/2010 06:05 PM, Felipe Pena wrote: I guess better to create a traits-specific class. Currently the ReflectionClass doesn't return information about traits. I do not see a need for Trait-specific reflection because of the flattening property (compiler-assisted copypaste). Well, the question would be more like do we want to expose that information in the reflection. At the moment it would certainly be possible. The information is there. I would considered it an optimization to drop it after it is not 'needed' anymore. But, instead of dropping it, it would also be possible to extend ReflectionClass to expose it. I would be in favor of exposing it. From a conceptual perspective it would be good to have a ReflectionTrait and ReflectionClass should have something like ReflectionClass::getTraits(). However, when it comes to methods, we have ReflectionMethod::getDeclaringClass() which also could return the corresponding trait. From an implementation perspective Traits are classes at the moment. So, well, for the reflection it would be the easiest to follow that approach, but it would not make things more clear to people trying to understand the differences. Writing up a proposal for a reflection api is definitely on my todo list, but I am not sure when I will be able to actually do it. Best regards Stefan -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/Zend/tests/traits/ error_001.phpt error_002.phpt error_003.phpt error_004.phpt error_005.phpt error_006.phpt error_007.phpt error_008.phpt error_009.p
Hi Felipe: Hope you don't mind that I post it on the list, think the discussion should be properly archived. On 06 May 2010, at 18:30, Felipe Pena wrote: Hello, 2010/5/6 Stefan Marr p...@stefan-marr.de Hi Felipe: On 05 May 2010, at 22:00, Felipe Pena wrote: One question... Looking at the grammar, I got a doubt... Is actually intended to allow constructions like 'trait foo extends ...' and 'trait foo implements ...' ? (I can't see an example like that on the RFC) The idea is that traits form its own hierarchy of composition, and since they can be composed from traits itself, it should not be necessary, to allow inheritance. So, no, extends and implements should not be allowed. The idea of allowing interfaces was rejected in the first big discussion. Interfaces belong to classes, and traits are solely meant to provide implementation. Since you can exclude methods, it does not fit well with the notion of interfaces. There are a number of things which are not quite clear in the grammar at the moment. My idea was that I just reuse the class grammar, and add exceptions for the situations which are not allowed. Mostly to avoid duplicating the relevant grammar parts. Do you think it would be better to do it the other way around, and use a dedicated grammar for traits? We could use a dedicated grammar or make the properly checks in the compiler. Both solutions looks good for me. I got a new question for you... Shouldn't we don't allow the implementation of magic methods and constructors in Traits? Hm, well, don't know, but I do not really see a reason to disallow magic methods. There are definitely use-case for something like __toString. Constructors are a complicated topic on its own. But in general, the initialization part might also be reusable. So, what would be your argument why they might be 'harmful'? Best regards Stefan -- Regards, Felipe Pena -- 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
Re: [PHP-DEV] Obscure token name
On 27 Apr 2010, at 08:50, mathieu.suen wrote: Then T_DOUBLE_COLON would have been perfectly clear. Honestly, token names in error messages is so '80s. Instead of fixing internal details, form the users point of view it might be better to not expose token names at all, but have meaningful parser errors. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/trunk/Zend/tests/ traits/bugs/abstract-methods01.phpt traits/bugs/abstract-methods02.phpt traits/bugs/abstract-methods03.phpt traits/bugs/abstract-methods04.phpt tr
Hi Sebastian: On 22 Apr 2010, at 15:37, Sebastian Bergmann wrote: Am 15.04.2010 23:39, schrieb Stefan Marr: Added traits test cases. No engine changes for now. [TRAITS] do you have an ETA for when the actual implementation will be committed? I am currently fighting with some of the changes which have accumulated since I last updated the patch. Currently, it looks like there is one memory leak left which makes most traits tests fail. I want to fix that before committing the first version. Which wont be perfect either, but at least more visible for comments. ETA: Well, ASAP BTW: I have not tried to compile the runkit extension, but I doubt that it will. I am using some code to copy methods which I needed to adapt to some changes in zend_op and related structs. Have not seen similar commits to runkit, so I guess it is broken. Best regards Stefan Thanks! Sebastian -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] traits
On 22 Apr 2010, at 22:17, Rasmus Lerdorf wrote: On 04/22/2010 01:05 PM, Stefan Marr wrote: I must have missed some emails, so which one of the numerous proposals is this based on? I have some comments on the tests, but I don't want to start with it befor it's clear which one we're talking about. I would commit the traits implementation[1] (not grafts). Just fixed the last immediately visible problem and am now in the process of writing up a list of open questions/todos for the implementation. There are some details in the patch which need to be reviewed and improved I think. None of this touches the executor, right, even the conflict resolution? Am not sure how you define the executor. Maybe that answers the question: http://svn.php.net/viewvc?view=revisionrevision=298348 All traits related operations are done when the class is compiled. Similar to how interfaces are handled. For the composition there is an additional opcode which concludes the compilation of a class and executes all merge/conflict resolution operations. After that is done, traits do not have any additional impact on the execution anymore. And I am assuming the class composition changes aren't going to blow up opcode caches? I really fear making the class composition more complicated than it already is. You can sit and stare at all the code required in APC to deal with that all day and still not get any wiser. Don't know exactly. There is a certain need to adapt the opcode caches, I would guess. 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote: On 12.04.2010, at 10:34, Derick Rethans wrote: Hi! Just had a look over the RFC, and from what I gathered was that only the issue of aliasing/renaming seems slightly controversional. Would it be possible to commit traits without this feature for now? Stefan recently got karma and told me he can commit his traits patch after the 15th. I do not really think we should leave out the aliasing, lets have as many people as possible play with it as is. We can always tweak/change/drop it later. Right, I am hunting an important deadline at the moment, so was going to split up the changes afterwards in step-wise patches, to make things easier digestible. But just as a quick response, without aliasing, there would be no way to use a conflicting method from a trait. On first sight, that is not a really good thing. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
On 12 Apr 2010, at 16:11, Jonathan Bond-Caron wrote:
On Mon Apr 12 05:16 AM, Stefan Marr wrote:
On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
On 12.04.2010, at 10:34, Derick Rethans wrote:
Hi!
But just as a quick response, without aliasing, there would be no way
to use a conflicting method from a trait.
On first sight, that is not a really good thing.
Hi Stefan, is it possible to have renaming and aliasing?
Some context, say we have:
trait Something {
function renameIssue() {
$method = 'call';
$this-$method();
call_user_func(array($this, $method));
}
function call () {echo a; }
function invokeCallDirectly() { $this-call(); }
}
class Foo {
use Something {
function call() as call2();
}
}
With renaming:
$f = new Foo;
$f-call2(); // a
$f-renameIssue();// call() method does not exist
I have added invokeCallDirectly() to your example. What should be the semantics
of that? Should that call be refitted to invoke call2?
Am not sure that this is a good idea, with all this other ways around to call
methods dynamically. Ok, aliasing is 'kind of annoying' and unusual but from my
perspective not much different then what we do with variables every day. They
reference objects, and we introduce new aliases for old objects every now and
then.
the syntax could re-use the 'clone' keyword:
class Foo {
use Something {
function call() clone call2();
}
}
Would be an option, but it reads kind of strange, doesn't it?
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
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: gron
I would like to contribute my Traits implementation to PHP. BTW, there is no Grafts implementation at the moment, and as long as there is not any vote from the community that you want Grafts but not Traits, I would like to commit my work. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: shorthand object property setting syntax.
On 27 Mar 2010, at 17:23, Martin Jansen wrote:
On 27.03.10 17:02, Toorion wrote:
$myLongNameObject = new MyLongNameObject();
$myLongNameObject-property1 = '1';
$myLongNameObject-property2 = '2';
$myLongNameObject-property3 = '3';
$myLongNameObject-property4 = '4';
$myLongNameObject-property5 = '5';
[...]
$MyLongNameObject = new MyLongNameObject() {
$property1 = '';
$property2 = '';
$property3 = '';
$property4 = '';
}
What exactly do you gain with the new syntax? You don't save LOC with
it (actually it requires one more line) and you still have to type all
the property names. Using an editor with code completion one can
produce the code in the current syntax pretty quickly after all.
LOC isn't a very useful metric anyway...
However, the proposal reminds me of Pascal's 'with'-construct:
http://en.wikipedia.org/wiki/Pascal_(programming_language)
new(pointertob);
with pointertob^ do
begin
a := 10;
b := 'A';
c := nil
end;
- Martin
--
PHP 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 - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: shorthand object property setting syntax.
However, the proposal reminds me of Pascal's 'with'-construct: new(pointertob); with pointertob^ do begin a := 10; b := 'A'; c := nil end; Can one do something like b := this.a? This sounds like a huge can of worms to me. Ehm, I don't see what might be problematic with b := this.a. However, I did not mean to propose it, I just thought I mention it. Think there was also a similar discussion (with respect to something similar to 'with') a while back. But since PHP requires you to write your '$this-' everywhere, such a construct does not feel very much inline with this rest of the language which is explicit. Back to the original proposal, from my point of view, source code is meant to be read, and repetition is handled easily by the human brain, a bit of alignment with whitespace and voilà... Best regards Stefan - Martin -- PHP 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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
On 26 Mar 2010, at 10:26, mathieu.suen wrote: Variable has been discuss in *http://tinyurl.com/y9t7nd9 Right, and related to that we have freezable traits http://scg.unibe.ch/scgbib?_k=NNRwidu5query=freezable+traitsdisplay=abstract Which influenced this RFC for PHP: http://wiki.php.net/rfc/nonbreakabletraits And there are traits based on lexical nesting, which does not seem to be applicable to PHP at all: http://scg.unibe.ch/scgbib?_k=J-wbMltVquery=tom+cutsem+bergel However, it still comes with a relatively high complexity, and a lot new concepts... The last time we had a lengthy discussion on this, and the conclusion was, people are afraid of this additional complexity. That was my reason to design grafts. 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 To unsubscribe, visit: http://www.php.net/unsub.php
