launchpad-dev team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 11 September 2010 22:04, Robert Collins <robert.collins@xxxxxxxxxxxxx> 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.