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 engin
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'
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 assignm
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
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,
