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;
}
$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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
