On Fri, Mar 31, 2023, at 1:07 PM, Ilija Tovilo wrote:
> Hi everyone
>
> A few days ago we received a bug report about an inconsistency with
> traits and static properties.
>
> https://github.com/php/php-src/issues/10935
>
> https://3v4l.org/Dll1m
> ```
> class A {
> static $test;
> }
> class B
Hi everyone
A few days ago we received a bug report about an inconsistency with
traits and static properties.
https://github.com/php/php-src/issues/10935
https://3v4l.org/Dll1m
```
class A {
static $test;
}
class B extends A {
static $test;
}
A::$test = 'A';
B::$test = 'B';
var_dump(A::$
Le 30/11/2020 à 16:19, Nikita Popov a écrit :
Common misconception: It's not possible to rename methods of traits, you
can only create aliases. That said, there's still an issue in that you
might resolve a conflict in favor of an identically named method that uses
a different signature.
Note tha
On Thu, Nov 26, 2020 at 5:53 PM Pierre R. wrote:
> Le 26/11/2020 à 17:50, David Rodrigues a écrit :
> > Hello!
> >
> > Now with PHP 8, traits supports abstract functions that should be
> > implemented by the class that uses this trait.
> >
> > So is it now possible that traits could have support
Le 26/11/2020 à 17:50, David Rodrigues a écrit :
Hello!
Now with PHP 8, traits supports abstract functions that should be
implemented by the class that uses this trait.
So is it now possible that traits could have support to implements too? So
when class uses this trait, it will be an implement
Hello!
Now with PHP 8, traits supports abstract functions that should be
implemented by the class that uses this trait.
So is it now possible that traits could have support to implements too? So
when class uses this trait, it will be an implementation of X interface and
will have to implement met
On 2 March 2018 01:38:37 GMT+00:00, "Pedro Magalhães" wrote:
>On Thu, Mar 1, 2018 at 11:04 PM, Rowan Collins
>
>wrote:
>>
>> What *can* break an interface's contract is changing the *visibility*
>of
>> the pasted method using "as protected" or "as private". This would
>need to
>> be captured someh
On Thu, Mar 1, 2018 at 11:04 PM, Rowan Collins
wrote:
>
> What *can* break an interface's contract is changing the *visibility* of
> the pasted method using "as protected" or "as private". This would need to
> be captured somehow while composing the class, probably producing a
> compile-time error
Hi all,
On 01/03/2018 00:34, Marco Pivetta wrote:
- trait defined API can be imported with changed/aliased names, breaking
therefore the contact defined in the interface
This isn't actually true, because trait method aliases create an *extra*
copy of the pasted method, rather than actually
> don't use traits
Yes, in general, yes.
Composition is great, and I use it most of the time.
I still do have some cases where I think that base classes (with
private properties) are justified, and then some cases where either
traits or multiple inheritance would be justified.
We could agree to se
This cannot work for a number of reasons:
- a trait is not a type, and does not practically exist at runtime
- trait defined API can be imported with changed/aliased names, breaking
therefore the contact defined in the interface
- due to the previous point, inheriting a type from a trait become
Why traits doesn't supports interfaces (via implements) like classes does?
It could be useful when trait implements part of abstract functions from
interface, then the class that uses this traits should implements the
another part.
It could turn it possible (pseudo-code):
interface VisibilityCon
On 07/31/2012 04:23 PM, Stan Vass wrote:
I'd like to point out some puzzling behaviors in Traits as they exist in the
production releases of PHP 5.4.
Regardless of the outcome of the mail thread, can you review the traits tests
and create new tests for
any behaviour not already covered?
Ch
On 01 Aug 2012, at 16:31, Stan Vass wrote:
>> Because it is not a matter of horizontal reuse.
>> Why don't you get a warning when you override an inherited method?
>> Because that is precisely the way things are supposed to work.
>>
>> The body of a class is not a trait. These methods are not 'e
I'd like to apologize for my language. My goal isn't to insult anybody,
especially PHP contributors of major features like traits.
I hope we can talk strictly implementation issues, I think I have a good
idea how we can move this forward, I'll email you a list of behavior changes
that I think
Because it is not a matter of horizontal reuse.
Why don't you get a warning when you override an inherited method?
Because that is precisely the way things are supposed to work.
The body of a class is not a trait. These methods are not 'equals'.
I still think that design decision is a sensible on
Hi Stan:
On 01 Aug 2012, at 14:56, Stan Vass wrote:
>> From that follows that traits override the super class's methods.
>> And, conflict resolution is only done between traits, not between a class
>> and its traits.
>> The class body is a definite thing. Why would you purposefully add something
From that follows that traits override the super class's methods.
And, conflict resolution is only done between traits, not between a class
and its traits.
The class body is a definite thing. Why would you purposefully add
something to a class body that conflicts with a trait?
The class needs to
Hi Stan:
On 01 Aug 2012, at 13:54, Stan Vass wrote:
>> 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.
>
>
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.
I'd like t
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.
Hi, I've subsequently read your RFC carefully and saw some of those
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:
> --
I'd like to point out some puzzling behaviors in Traits as they exist in the
production releases of PHP 5.4.
1. Name collisions between a trait method and a class method using the trait go
unreported, the class silently
During the flattening process, is a copy made of the trait
code (or bytecode or whatever)?
...
Or is the code shared so the memory use will be roughly the same?
...
I realise the use cases for traits and inheritance are
different, and often the situation will dictate the design,
but sometimes
On 10/04/12 5:42 PM, Stefan Marr wrote:
Hi Ben:
On 10 Apr 2012, at 03:34, Ben Schmidt wrote:
During the flattening process, is a copy made of the trait code (or
bytecode or whatever)?
Thanks to Dmitry, the op_array, i.e., the methods op codes are not
copied but shared between the methods.
Th
Hi Ben:
On 10 Apr 2012, at 03:34, Ben Schmidt wrote:
> During the flattening process, is a copy made of the trait code (or
> bytecode or whatever)?
Thanks to Dmitry, the op_array, i.e., the methods op codes are not copied but
shared between the methods.
Thus, there is a certain memory benefi
> -Original Message-
> From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
> Sent: 10 April 2012 02:35
> To: internals@lists.php.net
> Subject: [PHP-DEV] Traits and memory size
>
> Hi!
>
> Just a quick question about traits.
>
> During the flat
Hi!
Just a quick question about traits.
During the flattening process, is a copy made of the trait code (or
bytecode or whatever)?
So, if I have
trait A {
// a bunch of methods
}
class B {
use A;
}
class C {
use A;
}
class D {
use A;
}
will I have four copies of A because it has b
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
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 c
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 engin
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
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
On 3/01/11 8:57 PM, Stefan Marr wrote:
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-internals&m=129288735205036&w=2
Best regards
Stefan
OK, Stefan, I just got confused by read
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-internals&m=129288735205036&w=2
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 /
Hi, Stefan,
On 3/01/11 8:16 PM, Stefan Marr wrote:
On 03 Jan 2011, at 10:04, Ben Schmidt wrote:
In this email thread you seemed to be saying that properties defined in
traits are completely ignored, but in the RFC and svn it seems to be
saying that properties in traits are not ignored, but are
Hi Ben:
On 03 Jan 2011, at 10:04, Ben Schmidt wrote:
> In this email thread you seemed to be saying that properties defined in
> traits are completely ignored, but in the RFC and svn it seems to be
> saying that properties in traits are not ignored, but are merged into
> the class and/or trigger
Hi, Stefan,
Sorry, I do not understand.
Haha. Now we are both confused!
In this email thread you seemed to be saying that properties defined in
traits are completely ignored, but in the RFC and svn it seems to be
saying that properties in traits are not ignored, but are merged into
the class
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 p
On 3/01/11 2:24 PM, David Muir wrote:
On 12/12/10 01: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 trai
On 12/12/10 01: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 m
On Mon Dec 20 06:21 PM, Stefan Marr wrote:
>
> = Handling of Properties/State =
>
> This property handling was implemented in
> [[http://svn.php.net/viewvc?view=revision&revision=306476|SVN revision
> 306476]] and examples are given in the test cases.
>
+1
The E_STRICT warning seem
On Monday, December 20, 2010 5:21:08 pm Stefan Marr wrote:
> 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 th
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 Trait
On 12/20/10 7:53 AM, Matthew Weier O'Phinney wrote:
On 2010-12-19, Stefan Marr wrote:
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
On 2010-12-19, Stefan Marr wrote:
> 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 a
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 implementin
On 2010-12-18, Stefan Marr wrote:
> On 16 Dec 2010, at 23:31, Larry Garfield wrote:
> > - 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 ge
On Sat Dec 18 12:33 PM, Stefan Marr wrote:
> 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 inherit
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 i
On Sat Dec 18 10:29 AM, Stefan Marr wrote:
> 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.
> T
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 b
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?
2010/12/16 Stefan Marr :
> 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
On 2010-12-16, Stefan Marr wrote:
> 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
> arou
I like it,
additionally if you want to prevent conflicts from the start you can
always go and define prefixed property names like below and use a getter to
access them conveniently.
trait Foo
{
private $Foo_prop;
public function getProp()
{
return $this->Foo_prop;
Am 16.12.2010 16:25, schrieb Stefan Marr:
> From my point of view the right thing to do with regard to
> properties is defined in the test cases below.
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://
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 b
On Monday, December 13, 2010 10:02:13 am Stefan Marr wrote:
> 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
On Sun Dec 12 04:33 PM, Nathan Nobbe wrote:
>
>
> So the 'with/within' tokens would apply to traits.
>
> I feel 'expect', 'need', 'require' etc sound better, matter of opinion
> really, but it sounds like from an internals perspective it's
> preferred to reuse existing keywords if possible.
>
Hi Richard:
On 13 Dec 2010, at 14:31, Richard Quadling wrote:
> On 11 December 2010 23:31, Stefan Marr 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
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
On 11 December 2010 23:31, Stefan Marr 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 s
On 11 December 2010 16: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
> eith
On Sun, Dec 12, 2010 at 7:25 AM, Jonathan Bond-Caron wrote:
> On Sat Dec 11 10:25 AM, Stefan Marr wrote:
> >
>
> http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
> nt_interface
> >
> >
> > Are there any objections to implementing this?
> >
>
> It's not a bad idea, thoug
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
>
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
>
>
> Are there any objections to implementing this?
>
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
It als
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
On 12/12/2010 01:24 AM, Stefan Marr wrote:
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.
Good! :-)
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergman
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
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 hel
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/prop
On 12/11/2010 05:47 PM, Stefan Marr wrote:
Another way would be to merge the properties in the composing class.
+1
The question here would be how to treat visibility modifiers
One option would be to only allow private. That way only methods from
the trait would have access and collisions
On Sat, Dec 11, 2010 at 9:47 AM, 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
>
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
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 c
On Fri, Dec 10, 2010 at 2:42 PM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:
> On 2010-12-10, Nathan Nobbe wrote:
> > --0016e6d7e101e083a4049714bad3
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney <
> > weierophin...@php.ne
On Fri, Dec 10, 2010 at 1:00 PM, Nathan Nobbe wrote:
>>
>> As a note, I'm not strongly opposed to this proposal, since I don't
>> think it would do any harm. It just seems to me like a "kitchen sink"
>> feature.
>>
>> The issue for me is that traits, as I understand them, are there
>> primarily fo
On 2010-12-10, Nathan Nobbe wrote:
> --0016e6d7e101e083a4049714bad3
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney <
> weierophin...@php.net> wrote:
>
>> On 2010-12-10, Nathan Nobbe wrote:
>> > --0016e6dbe7fb8861a1049712ad63
>> > Content-Ty
On Fri, Dec 10, 2010 at 12:39 PM, Chad Fulton wrote:
> On Fri, Dec 10, 2010 at 10:39 AM, Nathan Nobbe
> wrote:
> > On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton
> wrote:
> >>
> >> On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe
> >> wrote:
> >> > On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstah
On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:
> On 2010-12-10, Nathan Nobbe wrote:
> > --0016e6dbe7fb8861a1049712ad63
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton
> wrote:
> >
> > > On Fri, Dec 10, 2
On 2010-12-10, Nathan Nobbe wrote:
> --0016e6dbe7fb8861a1049712ad63
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton wrote:
>
> > On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe
> > wrote:
> > > On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl
> > wrot
On Fri, Dec 10, 2010 at 10:39 AM, Nathan Nobbe wrote:
> On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton wrote:
>>
>> On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe
>> wrote:
>> > On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl
>> > wrote:
>> >
>> >> First i have to say that I am not a PHP inter
On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton wrote:
> On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe
> wrote:
> > On Fri, Dec 10, 2010 at 10:15 AM, 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 bett
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe wrote:
> On Fri, Dec 10, 2010 at 10:15 AM, 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
Oh, sorry, should have read the RFC thoroughly before sending an email.
But yeah, require might be a good choice, provided it doesn't collide with
the specific require logic in the scanner/parser (I don't have much
knowledge on that subject, but I've peeked a few times on it as it is
interesting).
On Fri, Dec 10, 2010 at 10:15 AM, 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?
>
This is actually in
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 se
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 specifie
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
> s
On Thu, Dec 9, 2010 at 4:04 PM, Stefan Marr wrote:
> 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 fu
Personally, I believed that traits are a *compile time injection* to a
class, so that at runtime a class behaves completely as it would if trait
methods were implemented directly in the class. That said, everything like
trait requirements for a certain interface, should be done at compile time
and
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. I
On Thu, Dec 9, 2010 at 1:09 AM, Stefan Marr wrote:
> Hi Nathan:
>
> On 09 Dec 2010, at 08:44, Nathan Nobbe wrote:
>
> > Hi,
> >
> > I think traits will lend themselves to frequent runtime checking against
> the
> > type of class in which they were used. Consider a trait designed for use
> > with
Hi Nathan:
On 09 Dec 2010, at 08:44, Nathan Nobbe wrote:
> Hi,
>
> I think traits will lend themselves to frequent runtime checking against the
> type of class in which they were used. Consider a trait designed for use
> with an Iterator class; the first thing might be to check the type of $thi
Hi,
I think traits will lend themselves to frequent runtime checking against the
type of class in which they were used. Consider a trait designed for use
with an Iterator class; the first thing might be to check the type of $this.
do you not think checks like this will be common / messy / perf
On Sun, 5 Dec 2010, Stefan Marr wrote:
> 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 me
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
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 mak
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 oth
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;
> }
ht
1 - 100 of 135 matches
Mail list logo
