Eric Crahen wrote:
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 see. I guess you are right that having descriptor as an inner class is
unnecessarily confusing. I did it so just because that keeps the number
of classes in my package explorer smaller.
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.
True.
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.
I guess this is where I need to understand you better. For example,
today I need descriptors for listing up the kind of Jobs that are
installed. If I remove getDescriptor(), how do I do that? and how do I
create a new Job instance?
Or once loaded, the global configuration (like where Ant is installed)
is stored in Ant's Descriptor object. If you get rid of that, where do
you keep it, in a way easy to persist?
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.
I really appreciate all your comments.
I'd like to get more contributions, so I don't want to cut a discussion
by declaring "I'll do it this way because this is mine!"
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi@xxxxxxx
smime.p7s
Description: S/MIME Cryptographic Signature
| 