Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: FW: Re: [dali-dev] class name changes
+1


From Neil Hauge <NEIL.HAUGE@xxxxxxxxxx>
Sent Fri 2/24/2006 8:25 AM
To General Dali EJB ORM developer discussion. <dali-dev@xxxxxxxxxxx>
Subject Re: FW: Re: [dali-dev] class name changes

Since we didn't discuss this any more yesterday, lets continue with the email discussion as opposed to having a meeting this morning.
 
Neil
 
From Paul Fullbright <paul.fullbright@xxxxxxxxxx>
Sent Thu 2/23/2006 11:03 AM
To General Dali EJB ORM developer discussion. <dali-dev@xxxxxxxxxxx>
Subject Re: FW: Re: [dali-dev] class name changes



Brian Vosburgh wrote:
Hmmm - I guess I don't like the verbosity of -AttributeMapping. But EmbeddableMapping and NullMapping sound misleading: It's not and "embeddable" mapping, it's a mapping of an "embeddable" type; and Null Mapping could apply to either an attribute or a type....
So I'd prefer:  Embedded, Embeddable, NullAttributeMapping (or some other substitute starting with something other than Null)
I think consistency is key.  My suggestion:  use the annotation name unless we're talking about an interface that doesn't strictly have an annotation.  (Id, Basic, ColumnAttributeMapping)
It's always difficult to invoke "consistency" as a rationale, because what you're being consistent with is arbitrary. I could likewise plead that class names should be nouns, for "consistency's" sake. Most of these objects look, act, and smell like Mappings (i.e. they associate an attribute with a database field etc.), so I think they should be called Mappings.
Everything is arbitrary at some level.  But I think that there should be some level of consistency with our naming.  We're just debating what that level of consistency is.
Comments:
It's not so much that "Persistent" modifies "AttributeMapping".  Rather, "PersistentAttribute" modifies "Mapping".  (This object maps a persistent attribute.)  But I agree that AttributeMapping encapsulates the same understanding.
As far as interface names and EMF, I'm planning to provide a second layer of interfaces on top of a group of EMF interfaces simply so I can hide all the crap that EMF generates from outside the plugin.  I want users to access the interfaces, but I don't want them to create instances or modify them, which EMF exposes.
What should the naming convention be as an alternative to:  FooImpl->Foo->IFoo?
The I naming convention, while perhaps discarded by many plugins, is pretty rigorously followed by both the platform and jdt, both of which we are working closely with.  Just sayin'.
Ouch. Discard EMF? ... When were you planning on coding these public-public interfaces and burdening us with yet another layer of protocols to keep in synch? :-)
Not discard.  Hide from the public.  Work is to be done at some future point.


- Paul
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev


_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev

Back to the top