Hi On Sunday 12 April 2009 02:31:29 glyph@divmod.com wrote:
This is a long and terrible road you're about to start down. It's hard for me to explain exactly why it's so painful, but trust me, it is.
No, I won't trust you :-) I hope you don't take what I'm going to say too seriously, but you couldn't sound more patronising. Anyway, if it's so hard to explain, it's probably harder to understand, and thus, it's something that you cannot figure out by yourself. So, if you don't mind, why do you think it's so bad?
What you're doing now, passing out-of-band arguments to the IFooFactory adapter, whose concrete type you are *not supposed to know* at that point in the control flow, is bad. But trying to force adaptation to become full-fledged multimethods is worse. If you want multimethods, I believe PEAK provides a package that implements them.
I know it's bad, because the resulting factory is incomplete, but that's why I wanted to adapt from two objects: the service itself and something that would make the factory complete (i.e. some configuration parameters required by protocols). The main problem I see with the current adapter registry, is that adapters aren't configurable. In our case, we have a bunch of services, which are exposed to AMQP (adapted into a factory that builds instances of the AMQP protocol class), but since this is a client protocol that needs some extra arguments that can't be set beforehand in the adapter (username, password, vhost, encoding), they are passed after the service has been adapted into a factory. So the problem is that the resulting factory is not complete, it doesn't have enough information to build protocols. The only workaround is to explicitly set those extra parameters after it has been instantiated.
If you want to keep doing what you're doing, you should do this:
factory = MyServiceFooFactory(myService) factory.configureBar("some value")
i.e. don't ask for an adaptation which might give you an object without a "bar" attribute, just create the concrete type that does what you need based on the type of myService and configure it with explicitly documented methods. Although if I misunderstand the spec of "IFooFactory" and it *does* include a bar attribute, nevermind.
The IFooFactory interface declares that attribute, but it's not immediately available when the service is adapted into a factory. I fail to see what's the difference between bar= and configureBar() in this particular case. Interface attributes can be documented, so I don't see what makes configureBar better than bar (which can be turned into a property). Anyway, I think both solutions are flaky, so that's why I thought adapting two interfaces would be more elegant.
If you want something more magical and adapter-ish, them maybe you want this:
IFooFactory(ConfigurationObject(myService, bar="some value"))
i.e. by the time you are getting around to the IFooFactory adaptation, you should have an object that fully provides enough information that the concrete FooFactory adapter type can be fully initialized when it is created.
I think that solution is even worse. That particular instance of ConfigurationObject is tied to myService: it can't be (de)serialized, reused with other adapters, ConfigurationObject and MyService are completely unrelated and I don't think the former should depend on the latter.
In order to implement this, registerAdapter would have to be able to take a tuple of interfaces, like this:
components.registerAdapter( AdaptToFactory, (IFooService, IConfigurationDescriptor), IFooFactory)
would that feature make sense? If so, I'll file an issue right now :-)
Unfortunately, much as I've been encouraging people to file tickets lately, no :). I don't think it makes sense.
I still think it does, but nobody wants to make the ticket count grow higher :-) Anyway, Zope already has this nifty thing called multi-adapters, which implement exactly what I described: http://www.muthukadan.net/docs/zca.html#multi-adapter but I always liked Twisted's adapter registry better and our application already uses it in quite a few places. I like being able to call IFoo(bar) and let the registry lookup an adapter automatically, instead of having to call getAdapter()/queryAdapter() Cheers.