Re: Exemplar configuration thoughts

On 1/29/07, Kohsuke Kawaguchi <Kohsuke.Kawaguchi@xxxxxxx> wrote:

I read your e-mail but it's not quite clear to me what problems you had
with Descriptors.

Describables/Descriptors are really like Objects/Classes, so I find
singleton semantics appropriate. If "it's easy to implement wrong,
and it's hard to confirm you implemented it right" as you say, I'd like
to fix it, though. Maybe I need to expand on Describable.getDescriptor()
javadoc?

I think a clearer explaination in the javadoc would help. I only figured out that it had to be a singleton after a lot of trial and error.
Other than that, I think it was just the circular dependency between product and factory. I couldn't find anywhere that the code really needed to ask a product (ExtensionPoint) what its factory (Descriptor) was, sans the jelly. That made me start thinking about weather there was a real value there since it didn't seem to be exploited. Oh, the other thing that made it confusing with out documentation was how the classes were nested. The Descriptors being nested static classes, within the product ExtensionPoint they create. Maybe its just me, but the factory class being nested within the thing it creates just made it a little harder to wrap my head around, though I'm sure its not a new idiom.

I do see it how it works better when I think of it in the Object/Class analogy though. That would be a good way to explain it in the docs.

The main difference I'm talking about when I say not so easy to implement right is that the end user really needs to understand that Descriptors are singletons and implement them as such. You can't enforce that or communicate that with a function signature. The language doesn't allow people the option to return a class other than what Object.getClass() dictates, that makes it really hard for a user to get wrong. I guess what I'm saying is from something like Object/Class there is enforcement there and the only way you can implement it is the "right way", where as with ExtensionPoint/Descriptor you have more rope to hang yourself with.

Now if you took getDescriptor() away, you suddenly don't have the problem of requiring a singleton. Any Descriptor could make the ExtensionPoint. You only need to add one to the Hudson instance, and I think that would be it. There's not a whole a lot of getDescriptor() that seemed to be needed, so this seemed simpler to me since the circular dependency is gone, and the singleton requirement is gone.

This was something I was starting to think about and I think I would be inclined to reduce the coupling between those two classes. That's just me though. Ultimately its your project, (which is great so far btw), so its up to you.

-- 

- Eric