After some
more thought on the subject I
am still somewhat up in the air as to how we should name the mapping
and type
hierarchy. Here is a summary of some of the options we’ve come up
with:
PersistentAttribute
has an *AttributeMapping
BasicMapping
(implements ColumnHolder) Basic
EmbeddedMapping
Embedded
IdMapping
(implements ColumnHolder) Id
*InvalidMapping
InvalidAttributeMapping
VersionMapping
(implements ColumnHolder) Version
TransientMapping
Transient
*RelationshipMapping
RelationshipAttributeMapping
*SingleRelationshipMapping
SingleRelationshipAttributeMapping
ManyToOneMapping
ManyToOne
*NonOwningMapping
NonOwningAttributeMapping
OneToOneMapping
OneToOne
*NonOwningMapping
NonOwningAttributeMapping
*MultiRelationshipMapping
MultiRelationshipAttributeMapping
OneToManyMapping
OneToMany
ManyToManyMapping
ManyToMany
PersistentType
has a *TypeMapping
*Entity
EntityTypeMapping
*Embeddable
EmbeddableTypeMapping
*MappedSuperclass
MappedSuperclassTypeMapping
*NullTypeMapping
NullTypeMapping
ColumnPersistentAttributeFlavor
should
just be ColumnHolder since it is implemented by mappings that hold a
Column. ColumnMapping makes it sound like we are referrring to a
mapping
with the Column annotation.
Changed
Reference to Relationship because
the spec refers to them as relationships
* these are
my own preferences. I
can’t seem to decide between BasicMapping/Basic, but I know I don’t
like the verbosity of BasicAttributeMapping. Some arguments for Basic
would be that annotation names would match the class names. That’s
also an argument against calling it Basic, it’s easier to type BasicM
into the Type chooser since there are several other classes called just
Basic. BasicMapping would work well in the UI since
BasicMappingComposite
is clearer than BasicComposite which could be anything. I think
Entity,
Embeddable, MappedSuperclass are already used as nouns and do not need
the
TypeMapping on the end. I tried to find consistent naming in the spec
to
help me decide between Basic/BasicMapping, but was unable to find a
pattern. I lean towards BasicMapping.
At the
moment I am thinking of changing
things to match the * items and leaving Basic/Id etc as they are. Then
we
can get a feel for whether we like that or whether we want to rename
those to –mapping
or –attributeMapping.
Any
objections or other thoughts?
Any one leaning one direction or the other?
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
