Hi Mike:
On Sat, Jul 23, 2011 at 6:49 PM, Mike Stowe 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
>
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.
If they are allowed to be different with one overriding the o
On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron 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?
>
Hi Alex:
On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky 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
Hi:
On Fri, Jul 22, 2011 at 5:17 PM, 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
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
> 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
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()
> {
>
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
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
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
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
18 matches
Mail list logo
