Re: [PHP-DEV] Magic quotes removal previous patch
patch applied to trunk and 5.4, had to resist not to apply it to 5.3 :D On Thu, Jul 21, 2011 at 6:54 PM, Adam Harvey ahar...@php.net wrote: On 21 July 2011 02:19, Pierre Joye pierre@gmail.com wrote: Now the only question remaining is which level warning we should use for the setter. I'm happy with E_CORE. Objections? None here. +1 for E_CORE_ERROR — it's exactly what it's for. Adam -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes removal previous patch
On 22 July 2011 12:30, Pierre Joye pierre@gmail.com wrote: patch applied to trunk and 5.4, had to resist not to apply it to 5.3 :D As the great collective once said, Resistance is futile. Surrender to your inner-borg. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4a2 trait attribute name conflict resolution
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
The traits RFC pretty clearly states that if a class method conflicts
with a trait method then the trait method will be ignored, which is
what's happening, but it says nothing about what happens to attributes
in that same condition. Is this a bug?
Thanks,
--
Alex Howansky
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
I was under the impression that traits were not supposed to have
properties at all:
From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a common
practice to give this requirements explicitly. This is possible with
abstract methods like it is used for abstract classes.
Is the support for properties the bug perhaps?
Anthony
On Fri, Jul 22, 2011 at 11:17 AM, 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
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Thanks,
--
Alex Howansky
--
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 22 July 2011 16:17, 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
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Thanks,
--
Alex Howansky
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] APC distribute cache/dump files?
Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. -- Alex Howansky smime.p7s Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On 22 July 2011 09:12, Alex Howansky alex.howan...@gmail.com wrote: That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. Traits definitely need to be able to support properties, IMO, so I'd say that the first behaviour just needs to be documented (and potentially a notice added). Either the trait or the class is going to have its property overwritten, so we should pick which definition wins and go from there. Adam -- 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
I agree with Adam, I think it would be nice to let the trait contain its own properties which can then be overwritten by the class properties. This way we could include default properties that the trait may be dependent on, while providing the opportunity to override individual properties to provide a specific reaction for the class the trait is used in. Just curious, if the trait property is set to private what happens? - Mike On Fri, Jul 22, 2011 at 11:18 AM, Adam Harvey ahar...@php.net wrote: On 22 July 2011 09:12, Alex Howansky wrote: That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. Traits definitely need to be able to support properties, IMO, so I'd say that the first behaviour just needs to be documented (and potentially a notice added). Either the trait or the class is going to have its property overwritten, so we should pick which definition wins and go from there. Adam -- --- My command is this: Love each other as I have loved you. John 15:12 ---
Re: [PHP-DEV] APC distribute cache/dump files?
On 07/22/2011 08:56 AM, John Carter wrote: Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Nope, no such plans. Protect your code with a license. -Rasmus -- 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
Traits definitely need to be able to support properties, IMO Well, if traits support properties, they stop being traits and become mixins. A trait is nothing more than a mixin that does not have a state (so no properties). I'm not saying that it wouldn't be useful to contain properties (and hence state), but the RFC was for traits, they are called traits, and the RFC does mention that they shouldn't contain state. So a trait (by definition) should be purely behavioral (methods only). So, based on that, it does indeed seem like a bug to me that they currently support properties. If properties are to be supported, then why don't we rename the trait to a mixin and have some semblance of consistency... Anthony On Fri, Jul 22, 2011 at 12:18 PM, Adam Harvey ahar...@php.net wrote: On 22 July 2011 09:12, Alex Howansky alex.howan...@gmail.com wrote: That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. Traits definitely need to be able to support properties, IMO, so I'd say that the first behaviour just needs to be documented (and potentially a notice added). Either the trait or the class is going to have its property overwritten, so we should pick which definition wins and go from there. Adam -- 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] 5.4a2 trait attribute name conflict resolution
Didn't send to list the first time, please accept my apologies if you
received this twice - Thanks
That makes sense if it would overwrite the methods as well, but otherwise it
seems like it provides inconsistent functionality. Perhaps I'm wrong as
likewise I have a very limited understanding here.
- Mike
-- Past Conversation ---
-
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.
Richard
-
I was under the impression that traits were not supposed to have
properties at all:
From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a common
practice to give this requirements explicitly. This is possible with
abstract methods like it is used for abstract classes.
Is the support for properties the bug perhaps?
Anthony
-
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
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Alex
Re: [PHP-DEV] APC distribute cache/dump files?
hi, The 4.x plans went a bit to nowhere while there are good ideas in there. Moving the user cache out of the opcode cache is one of them. At the same time we could prepare something to have a driver based (simple) cache API. I plan to add persistent caching in the next couple of month so I may do this as well, as long as Gopal or Rasmus are fine with the idea. On Fri, Jul 22, 2011 at 5:56 PM, John Carter jcar...@identitynetworks.com wrote: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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
Just curious, if the trait property is set to private what happens? Ooh, good question. PHP Fatal error: baz and foo define the same property ($zoo) in the composition of baz. However, the definition differs and is considered incompatible. -- Alex Howansky smime.p7s Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] APC distribute cache/dump files?
I know the political discussions like not needed etc. But imho it might also be useful in corner-cases when you'd need an on-disk-cache etc. So if we have a volunteer to add it and it could maybe be done cleanly (plugin-API, ...) I'd appreciate if you'd allow him to try to come up with a solution :-) Regards, Stefan On 07/22/2011 06:15 PM, Pierre Joye wrote: hi, The 4.x plans went a bit to nowhere while there are good ideas in there. Moving the user cache out of the opcode cache is one of them. At the same time we could prepare something to have a driver based (simple) cache API. I plan to add persistent caching in the next couple of month so I may do this as well, as long as Gopal or Rasmus are fine with the idea. On Fri, Jul 22, 2011 at 5:56 PM, John Carter jcar...@identitynetworks.com wrote: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC distribute cache/dump files?
I know the political discussions like not needed etc. But imho it might also be useful in corner-cases when you'd need an on-disk-cache etc. So if we have a volunteer to add it and it could maybe be done cleanly (plugin-API, ...) I'd appreciate if you'd allow him to try to come up with a solution :-) Regards, Stefan On 07/22/2011 06:15 PM, Pierre Joye wrote: hi, The 4.x plans went a bit to nowhere while there are good ideas in there. Moving the user cache out of the opcode cache is one of them. At the same time we could prepare something to have a driver based (simple) cache API. I plan to add persistent caching in the next couple of month so I may do this as well, as long as Gopal or Rasmus are fine with the idea. On Fri, Jul 22, 2011 at 5:56 PM, John Carter jcar...@identitynetworks.com wrote: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC distribute cache/dump files?
The original question was for something akin to Zend Guard which is an encryption mechanism. There really are no plans for that. -Rasmus On 07/22/2011 09:40 AM, Stefan Neufeind wrote: I know the political discussions like not needed etc. But imho it might also be useful in corner-cases when you'd need an on-disk-cache etc. So if we have a volunteer to add it and it could maybe be done cleanly (plugin-API, ...) I'd appreciate if you'd allow him to try to come up with a solution :-) Regards, Stefan On 07/22/2011 06:15 PM, Pierre Joye wrote: hi, The 4.x plans went a bit to nowhere while there are good ideas in there. Moving the user cache out of the opcode cache is one of them. At the same time we could prepare something to have a driver based (simple) cache API. I plan to add persistent caching in the next couple of month so I may do this as well, as long as Gopal or Rasmus are fine with the idea. On Fri, Jul 22, 2011 at 5:56 PM, John Carter jcar...@identitynetworks.com wrote: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks -- 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 11:17 AM, Alex Howansky wrote:
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
The expected behavior is an E_STRICT notice:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/property001.ph
pt?view=markuppathrev=306476
If the modifier is different/conflicting (public, protected, private)
E_FATAL
http://svn.php.net/viewvc?view=revisionrevision=306476
http://marc.info/?l=php-internalsm=129251322332367w=2
The theory is traits should not have conflicting state/properties.
Best practice, always choose trait property names carefully/~unique so that
you don't run into conflicts.
The short answer is it's not a bug but maybe an implementation issue...
should it be an E_WARNING instead of E_STRICT?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC distribute cache/dump files?
yeah, just re read it and I realized that I miss the zend guard part, which is definitively not on my todos, and will never be :) On Fri, Jul 22, 2011 at 6:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: The original question was for something akin to Zend Guard which is an encryption mechanism. There really are no plans for that. -Rasmus On 07/22/2011 09:40 AM, Stefan Neufeind wrote: I know the political discussions like not needed etc. But imho it might also be useful in corner-cases when you'd need an on-disk-cache etc. So if we have a volunteer to add it and it could maybe be done cleanly (plugin-API, ...) I'd appreciate if you'd allow him to try to come up with a solution :-) Regards, Stefan On 07/22/2011 06:15 PM, Pierre Joye wrote: hi, The 4.x plans went a bit to nowhere while there are good ideas in there. Moving the user cache out of the opcode cache is one of them. At the same time we could prepare something to have a driver based (simple) cache API. I plan to add persistent caching in the next couple of month so I may do this as well, as long as Gopal or Rasmus are fine with the idea. On Fri, Jul 22, 2011 at 5:56 PM, John Carter jcar...@identitynetworks.com wrote: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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 Jul 22, 2011, at 9:32 AM, Alex Howansky wrote: Just curious, if the trait property is set to private what happens? Ooh, good question. PHP Fatal error: baz and foo define the same property ($zoo) in the composition of baz. However, the definition differs and is considered incompatible. And while people have traits on the mind, please also review the three open bug reports which also discuss how trait behavior should be defined: https://bugs.php.net/search.php?search_for=traitcmd=display Regards, Philip -- 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
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. -- Alex Howansky smime.p7s Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] APC distribute cache/dump files?
2011.07.22 18:56 John Carter rašė: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Are you sure that you are looking at the right pecl extension. http://pecl.php.net/package/bcompiler -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC distribute cache/dump files?
On Fri, Jul 22, 2011 at 7:04 PM, Pierre Joye pierre@gmail.com wrote: yeah, just re read it and I realized that I miss the zend guard part, which is definitively not on my todos, and will never be :) On Fri, Jul 22, 2011 at 6:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: The original question was for something akin to Zend Guard which is an encryption mechanism. There really are no plans for that. -Rasmus John maybe mentioned Zend Guard as an example, but imp he didn't suggested to add the feature set of ZG, only that it would be a nice feature, if APC would support dumping/restoring the cache. this way for example you could add this to your build/deployment workflow, so you don't have to warmup your cache on N machine for optimal performance. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC distribute cache/dump files?
On 07/22/2011 10:59 AM, Ferenc Kovacs wrote: On Fri, Jul 22, 2011 at 7:04 PM, Pierre Joye pierre@gmail.com wrote: yeah, just re read it and I realized that I miss the zend guard part, which is definitively not on my todos, and will never be :) On Fri, Jul 22, 2011 at 6:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: The original question was for something akin to Zend Guard which is an encryption mechanism. There really are no plans for that. -Rasmus John maybe mentioned Zend Guard as an example, but imp he didn't suggested to add the feature set of ZG, only that it would be a nice feature, if APC would support dumping/restoring the cache. this way for example you could add this to your build/deployment workflow, so you don't have to warmup your cache on N machine for optimal performance. Ah, but if it is for performance reasons, there is very little to be gained. The big win with APC comes from eliminating disk activity by pointing the executor directly at the op_array along with the in-memory function and class caches stored in shared memory. Restoring these from disk and sorting out where things go in memory is not going to be any quicker than simply recompiling the file. If we had a better opcode structure it theoretically could be faster, but as it is it would take a lot of work to get very small gains. -Rasmus -- 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 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
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.
Part of the problem is if you have something like:
trait foo
{
private $zoo = 'important_do_not_modify';
public function showZoo(){
echo $this-zoo;
}
public function doSomething(){
if($this-zoo !== 'important_do_not_modify') die('bad');
}
}
class baz
{
use foo;
private $zoo = 'modified';
}
$obj = new baz();
$obj-bar();
echo $obj-showZoo(); // modified
echo $obj-doSomething();
You can essentially 'break' the trait. So if you think of using someone
else's library/trait, it's not fun either when you break something without
knowing it.
But even then, I'm with you on allowing to change the default property value
in the composing class (I'm in favor of it).
What traits would likely need is:
trait foo
{
trait $zoo = 'important_do_not_modify';
public function doSomething(){
if(trait::$zoo !== 'important_do_not_modify') die('bad');
}
}
So that traits can keep their own private state (Ben Schmidt's idea)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC distribute cache/dump files?
On Friday 22 July 2011 11:17 AM, Rasmus Lerdorf wrote: On 07/22/2011 10:59 AM, Ferenc Kovacs wrote: On Fri, Jul 22, 2011 at 7:04 PM, Pierre Joyepierre@gmail.com wrote: yeah, just re read it and I realized that I miss the zend guard part, which is definitively not on my todos, and will never be :) On Fri, Jul 22, 2011 at 6:46 PM, Rasmus Lerdorfras...@lerdorf.com wrote: The original question was for something akin to Zend Guard which is an encryption mechanism. There really are no plans for that. -Rasmus John maybe mentioned Zend Guard as an example, but imp he didn't suggested to add the feature set of ZG, only that it would be a nice feature, if APC would support dumping/restoring the cache. this way for example you could add this to your build/deployment workflow, so you don't have to warmup your cache on N machine for optimal performance. Ah, but if it is for performance reasons, there is very little to be gained. The big win with APC comes from eliminating disk activity by pointing the executor directly at the op_array along with the in-memory function and class caches stored in shared memory. Restoring these from disk and sorting out where things go in memory is not going to be any quicker than simply recompiling the file. apc_bin_load/_dump() functions clearly illustrate how this does not really give any benefit for an apache based instance. Although, it does work really well if you are say, running phpunit tests with a large project (and yeah, I've got a bug to fix for the drupal/drush folks). Cheers, Gopal -- http://notmysock.org/blog/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
