[...] > Suppose we want to proxy one type, and use another type as mixin. If we call > common interface's member on the proxy, the call will be invoked on mixin, > not on target, which I consider a bug.
[...] > If we have such situation, we may rather want to throw an exception > explaining that mixin and target type both implement the same interface, and > that it's not a right thing to do. > On the other hand, this may be a valid choice, so we might prefer to allow it. > Things get even more complicated if we have multiple mixin instances that may > implement the same interfaces. Currently this results in an exception. I > think we probably should disallow it and throw an exception (but not > IndexOutOfRange as it is now, but something more descriptive). > I don't really know since I use mixins rarely myself. Any opinions? I'm not sure, either. With re-motion's mixin implementation, we definitely want to have this as a configuration option (ie. if you have a class C and mixins M1 and M2, you should be able to configure which of the interface implementations takes precedence). If no configuration is given, an error should occur. With DynamicProxy, it's different; its mixin mechanism is very basic anyway. IMO, we should forbid this situation and throw a sensible exception when it occurs. An interface should come either by the class or by at most one mixin. Making this configurable would be overkill, I think. Making it silently behave one way or the other would be unintuitive. Fabian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
