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
|