On 11 September 2010 22:04, Robert Collins <[email protected]> wrote: ... > This seems to draw a fairly large bow : adaption not working in one > context -> don't use adaption anywhere.
Yeah, this is my main concern. > > I think the declarative adaption facilities of the ZCA are great; but > that adaption isn't a panacea : the boilerplate you described would be > better written with delegation, not adaption. Fair. The example was taken from StructuralSubscriptionTargetMixin, and delegation would work well there. The classes that inherit this mixin, Product for example, are fairly big already so my thinking was along the lines of: - I wouldn't want to add yet more responsibility to these classes, - Being able to say "give me an object that lets me query and modify structural subscriptions for this thing" sounds good, - Adaption seems like a good way to do that, and relieves the already large classes from all responsibility, I might be wielding a hammer and seeing nails. Would you consider adapters for this scenario? > # Note that writing it this way makes it reasonably clear that we > # aren't using delegation/composition as much as we could in this area. > self.populateArgs() > > Similarly, I'm very unconvinced that using adaption for the property > cache was useful or helpful. I like the new API, but it seems like it > could be more pithy, more reusable and faster if it was just plain > python. I was tempted by the ZCA! I honestly thought we might need the flexibility that could bring, but turns out we didn't. So the best way to fix bug 628762 is probably to do away with adaption, but I'd like to repair my confidence in Zope too (or repair my knowledge). Gavin. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
