Hi Larry,
Also, at the risk of scope creep I will ask if any sort of runtime
knowledge
is being considered? That is, would there be a way to at runtime
get a list
of all traits that a given class is using, or access them separately?
well, the reflection API will be extended to be able to
On Saturday 18 April 2009 12:57:19 pm Stefan Marr wrote:
> Hi Stan,
>
> > I see this in a much simpler fashion. Treat traits as a preprocessor
> > step semantically.
> >
> > Internally, trait methods on multiple classes may point to the same
> > method to save resources, but in my opinion there's n
trait Counter {
var $value;
public function inc() { $this->value++; }
...
}
trait Color {
var $hue;
var $saturation;
var $value;
public function getRGB() { /* ... */}
...
}
class MyClass {
use Counter, Color;
}
Ok, you could argue that you than will have to refactor your prope
Hi Stan,
I see this in a much simpler fashion. Treat traits as a preprocessor
step semantically.
Internally, trait methods on multiple classes may point to the same
method to save resources, but in my opinion there's no need to
complicate matter by introducing new resolution rules, scopes
The question here is how to handle property accesses, in particular
accesses to unspecified properties.
I actually would expect to have a lookup mechanism which first looks in
the trait, and if the property is not found there, its going to the
object. I expect this behavior, because it is simil
Hi Tom,
On 17 Apr 2009, at 19:20, Tom Boutell wrote:
How ever, there are also corner cases. (Behavior might be different
in case
of name clashes for dynamically created properties within a
composition,
changing behavior depending on the order of method invocations on a
single
object)
I'm
On Fri, Apr 17, 2009 at 10:16 AM, Stefan Marr wrote:
> For the sake of simplicity, we might discuss a very basic solution.
> It would be possible to introduce trait-local state only.
> Thus, all properties defined in a trait are only available within methods of
> the same trait,
> no other operat
Hi Tom,
On 15 Apr 2009, at 16:13, Tom Boutell wrote:
PHP needs "real" horizontal reuse, no question.
Looking forward to get this discussion running once again after 5.3 is
released :)
My first reaction to traits was positive - it's simple and simple is
good.
However I'm very concerned abo
I've been catching up with the discussion of grafts and traits. Here
at P'unk Avenue we do a lot of Symfony development, which frequently
involves kludges to achieve horizontal reuse - ugly, clever,
imaginative, combinations of the three but the first of the three is
pretty much always present. PHP
On Nov 24, 2008, at 9:27 PM, Christopher Vogt wrote:
Interfaces are helpful in combination with type hinting, but for
people who prefer
duck typing, it is reasonable to not explicitly define them.
It sounds like you are saying that if you prefer duck typing then
interfaces have no use.
I
Hi Christopher,
thanks for (re-)starting the discussion how to make horizontal reuse
easier in PHP.
Am Donnerstag, den 13.11.2008, 16:59 +0100 schrieb Christopher Vogt:
[...]
> I had a chat with Stefan about his Traits/Grafts RFC and he suggested we
> should rather continue a discussion here.
> I
Hi,
On 25 Nov 2008, at 13:39, Marcus Boerger wrote:
Your points are all well observed. And yes I limit what my approach
can
do in order to Keep It Simple Safe (KISS). While still being able to
manually interfere with/overload the autogenerated code when
necessary.
At the same time forcing
Hello Christopher,
Tuesday, November 25, 2008, 3:27:45 AM, you wrote:
> Hej Marcus,
> I like your approach. It is clear and simple. It would probably solve
> 90% of the cases, where delegation is needed.
> I want to add that a manually defined method should automatically
> overwrite a delegated
Hej Marcus,
I like your approach. It is clear and simple. It would probably solve
90% of the cases, where delegation is needed.
I want to add that a manually defined method should automatically
overwrite a delegated method of the same name.
But I also want to bring up two reasonable situations y
Hello Stefan,
Sunday, November 16, 2008, 4:36:18 PM, you wrote:
> Hi,
> Christopher Vogt schrieb:
>> Hej everybody,
>>
>> I really liked to see the Grafts proposal.
> Well, I'm still in love with the more powerful (because they are
> interweaveable(breakable)) Traits ;)
>> The Grafts proposa
Hej,
>> I really liked to see the Grafts proposal.
> Well, I'm still in love with the more powerful (because they are
> interweaveable(breakable)) Traits ;)
I don't think there has to be a choice between Grafts and Traits. They
serve different purposes and I don't see a reason they shouldn't
co-e
Hi,
Christopher Vogt schrieb:
Hej everybody,
I really liked to see the Grafts proposal.
Well, I'm still in love with the more powerful (because they are
interweaveable(breakable)) Traits ;)
The Grafts proposal, however, suffered a little from being born out of
traits, I think. Something si
Hej everybody,
I had a chat with Stefan about his Traits/Grafts RFC and he suggested we
should rather continue a discussion here.
I really liked to see the Grafts proposal. In traits and regular
inheritance the implementation code of several entities is somehow mixed
and as a result one entities
18 matches
Mail list logo
