Re: [hibernate-dev] ServiceRegistry naming
On Mon 26 Sep 2011 11:09:56 AM CDT, Emmanuel Bernard wrote:
For 2,
The hard part is to understand when a given registry is used and for what purpose.
Not sure I understand what you mean here. Used in what way?
For lookups? Well the lookups are hierarchical. Thats not an issue at
all imho.
In terms of constructing? I just described when each is used. And
certainly "bootstrap" leaves little interpretation imho. And honestly,
the 3rd one is really an implementation detail that users should never
see. Not sure what other name is more appropriate for the
SessionFactoryServiceRegistryImpl one anyway;
SessionFactoryAwareServiceRegistryImpl? So really we have this
"bootstrap" registry and the "other" one to name properly. And as
for
the actual constructing, I think the API does a decent job of directing
that. A org.hibernate.service.ServiceRegistryBuilder is the thing
users utilize to build these registries. There are 2 forms of
constructing said builder: one is no arg and the other accepts a
BootstrapServiceRegistryImpl.
But if I am simply being "defensive" of my design, NOW is the time to
address any real shortcomings. I just don't see that particular issue.
I do see the names as confusing, particularly the "basic" one.
In a way Basic, Main, Core, Generic (the alternate names I can think
of) are not telling very much. The Basic registry holds services that are used at most
stages of Hibernate. Would Global make any sense?
Second best thing would be to Javadoc them a bit more to solve the problem.
I agree those terms do not shed much light on its function. But
really, what is its function? It is the registry that holds the
main/standard set of Hibernate services. Really the non-special
services if you look at it from the perspective that the other 2
registries are special purpose.
Global is completely inappropriate imo. I think it sets the wrong
impression. Global in what way? Especially when you consider that
Hibernate historically used the term "global" to discuss
class-loader-static configuration settings. Thats definitely not the
case here.
As far as the additional CR, That's a good question. I have no
opinion. I'd say it depends if you have time :)
I guess it depends whether the user-facing API is affected which it
probably would be if we renamed one/more of these. I'd rather get it
right for 4.0 versus 4.x
--
steve(a)hibernate.org
http://hibernate.org