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
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
Yes, my intention was to only add a magic constant with the class, similar
to this
namespace Bar {
class Foo {
const KLASS = __CLASS__;
}
}
namespace Buzz {
use \Bar\Foo as BazFoo;
class Bar extends BazFoo {
const KLASS = __CLASS__;
}
$bar = new Bar;
$baz = new BazFoo;
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
On Sun Jan 2 07:16 AM, Ben Schmidt wrote:
I would also like to propose some extensions to the functionality as
currently described, which I think could potentially add tremendous
power to the mechanism, with relatively little additional conceptual
complexity and implementation effort. I've
Hi Ben:
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
While it's still in the pre-release stage, though, I would like to put
in a vote for the assignment syntax: I think it is a lot easier to read
and understand than the 'insteadof' syntax.
The reason to go with insteadof is that the
Hi Ben:
Here the second part, on your extension proposal.
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
Extension
- - - - -
I suggest these two problems can be simply solved by introducing two
additional uses of the trait keyword: as a scoping keyword and an access
specifier.
As a
Hi Ben:
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
Proposal
I would therefore like to propose an extension backwards-compatible with
the current trait implementation. I will, however, extend the assignment
syntax, rather than the 'insteadof' syntax, as I find that clearer, and
