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 Joye 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
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 imp
On 07/22/2011 10:59 AM, Ferenc Kovacs wrote:
> On Fri, Jul 22, 2011 at 7:04 PM, Pierre Joye 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 wrote:
>
On Fri, Jul 22, 2011 at 7:04 PM, Pierre Joye 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 wrote:
>> The original question was for something akin to Z
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"
> 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?
> Th
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
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 wrote:
> The original question was for something akin to Zend Guard which is an
> encryption mechanism. There really ar
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()
> {
>
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
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 solut
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 solut
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/MIM
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 d
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 her
> 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 he
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.
-R
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
provi
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
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
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[]=
On 22 July 2011 16:17, Alex Howansky 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 metho
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
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 $zo
On 22 July 2011 12:30, Pierre Joye 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.l
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 wrote:
> On 21 July 2011 02:19, Pierre Joye wrote:
>> Now the only question remaining is which level warning we should use
>> for the setter. I'm happy with E_CORE. Objections?
>
26 matches
Mail list logo
