Re: Encapsulating Derivation

> > So, the questions:
> > Do we want to switch to encapsulating derivation?
> > Do we want to extend the Support LFB Class reporting to support
> > substitutability?
> >
>
>Hate to be the party pooper, but my answer to both is No. Main reason is
>I am already overwhelmed with too many features. In my experiences so
>far i have found myself always declaring from scratch even on related
>LFBs - so even the main justification of "avoiding redeclaration" is not
>meaningful to me. I would go as far as say kill this feature because the
>room for pitfalls is just unpredictable. If that is too much to ask for
>then keep it simple, lets get some deployment/interop experience and
>revisit in next reincarnation of the model RFC.
I agree with jamal that currently not switch to the encapsulating 
derivation for upredictable bugs,but I think we should support LFB 
substitutability because it's a important and should support feature.I 
agree with joel to add it as an LFB's property. Also i think it's not 
necessary to add a whole tree of supported parent class,we could use divide 
and conquer method and each LFB responsible for its own parent class 
querys.
Yours,Fenggen

_________________________________________________________________
涓虹杩琛浜ゆ锛璇蜂娇 MSN Messenger:  http://messenger.msn.com/cn