On Fri, Feb 22, 2008 at 10:32 AM, David Coallier <[EMAIL PROTECTED]> wrote:
>
> On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> >
> > On 22.02.2008, at 15:45, Gregory Beaver wrote:
> >
> > > Marcus Boerger wrote:
> > >> Hello Lukas,
> > >>
> > >> alright,
> > >>
> > >> 'foo as bar' is ok to me and does not even add a new keyword.
> > >> Ignore or any more keywords are bad and I also think that the correct
> > >> would be hide(ing). But as I further more explained it should
> > >> really be
> > >> something that only marks a method as private if at all. That can be
> > >> done as:
> > >> 'foo as private' since private is a keyword it cannot conflice
> > >> anyway.
> > >
> > > I like this solution.
> >
> > Yes to me it seems like we can solve the entire "lack of
> > encapsulation" through aliasing/hiding by making the following changes
> > to the original proposal:
> >
> > A trait may contain methods and properties. When importing a trait
> > into a class, all methods and properties are imported in a way that
> > makes them only visible within the trait (I dont like the use of
> > "private" here .. its what confused me in the first proposals of this
> > approach by Marcus/Andi). The user of the trait can however explicitly
> > make properties and methods from the trait visible to the class
> > importing the trait. Also the trait using class can explicitly say
> > that it wants to override a method/property in the scope of the trait.
> >
> > This way:
> > 1) there is little chance of accidentally breaking a trait
> > 2) changes within the trait should not break anything in the trait
> > using class, unless the developer explicitly messed with the traits
> > internals in the class using the trait. in that case however he can
> > quickly spot the potentially problematic lines
> >
> >
> > > I have been uncomfortable with the current trait suggestions because
> > > they occur in the body of the class, whereas extends/implements is
> > > outside. I think there is a way to handle this, however.
> >
> > I dont agree here. traits are different. They do not affect "what" the
> > class is. They change what it can do and as such the stuff should be
> > defined next to properties and methods.
> >
> > >
> >
> > > <?php
> > >
> > > trait trait1 { function a(){}}
> > > trait trait2 { function a(){}}
> > > class Blah extends ... implements ... traits trait1, trait2, trait3 {
> > > }
> > > ?>
> >
> > Here it gets worse. Now if I refactor things into a trait, I have to
> > start changing all uses of those methods.
> >
> > @Greg: I think you are going in the wrong direction here.
> >
>
> Fun that you mentionned that structure greg because I was thinking of
> something along those lines. Something very similar actually but the
> aliasing could look like this:
>
> trait One {
> function name() { return __TRAIT__; }
> function removeMe() {}
> }
>
> trait Two {
> function name() { return __TRAIT__; }
> }
>
> class Reel traits One, Two
> {
> override One::name with Two::name;
> remove Two::removeMe;
It is of course
remove One::removeMe;
> }
>
>
> $object = new Reel();
> echo $object->name(); // Echos "Two" of course.
>
>
> I find that rather clean and clear that you we are either overriding
> what with what and then removing a method. But as lukas mentionned, we
> may be stepping out of line here...
>
>
>
> > regards,
> > Lukas
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> David,
> Re-read what you are replying.
>
--
David,
Re-read what you are replying.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
