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
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
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
>
42 matches
Mail list logo
