I guess Project Lombok could be extended for this.
You would be inviting the same problems encountered by C++ with its
multiple inheritance,
and all that magic will probably make things harder to follow.
But; like all shotguns, it's everyone's responsibility where they aim,
lest they shoot themselves in the foot.
:D
On Sun, 2011-01-09 at 10:00 +0200, Martin Makundi wrote:
> >>> Either way, you have to put logic somewhere that tries to figure out
> >>> what the heck you want to borrow and then figure out where the heck to
> >>> get it.
> >>
> >> If it is done at compile time you don't need "messaging" logic. It
> >> would be uniquely defined what you can get.
> >
> > Please explain.
>
> Think about object hierarchy. It is uniquely defined what method
> overrides what etc.
>
> So it would just expand the same idea to "membership dimensions" in
> addition to "inheritance dimensions".
>
> I mean that assuming man has a bag would work effectively similar to
> man extends bag at compile time.
>
> If bag has a getter then man can expose that getter. However, if we
> would really extend bag then we are stuck with it (and we could'nt
> have man wear both jacket, trousers and bag at same time).
>
> When man only "has" bag then we can also change the bag and extend the
> bag with another bag or set it to null even.
>
> Nevertheless, we could annotate:
>
> @DefaultExpose(ExposeLevels.ALL)
> public class Man {
> private Bag bag;
> }
>
> public class Customs {
> public boolean investigate(Man man) {
> Pencil = man.getPencil();
> }
> }
>
> :::: Alternatively you can move the annotation
>
> public class Man {
> @DefaultExpose(ExposeLevels.ALL)
> private Bag bag;
> }
>
> ::: or even more detailed:
>
> public class Bag {
> @DefaultExpose(ExposeLevels.ALL)
> private PencilCase pencilCase;
> }
>
>
> Override rules could be same as "as if" the Man extended Bag and as if
> Bag extened PencilCase.
>
> **
> Martin
