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'.
That’s
because the platform and jdt
don’t have access to EMF.
Questions:
Why is it that you prefer Id->IdMapping, but think that Entity is
fine by
itself?
Why use -TypeMapping for implementations of that interface but not
-AttributeMapping
for implementations of that one?
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)
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'.
- Paul
Brian Vosburgh wrote:
Hear! Hear! :-) I agree that
the names should be
changed as you suggest. Comments on the issues you mentioned:
- GeneratorPersistentAttributeFlavor
[which is a really misleading
name] -> seems like this behavior should be rolled into IdMapping,
unless there is some future usage I am missing(?)
- Id
-> IdMapping (I think this is a fine name; Mike is in no position to
complain if he can't come up with an alternative - besides, he's not
doing the work!)
- NullPersistentAttributeFlavor
-> I like InvalidMapping (MissingMapping? :-) )
- Transient
-> TransientMapping seems OK; this could even be called NullMapping
since this is the "Mapping" that does nothing; but "TransientMapping"
would be a bit more helpful and easier to find
- Yes, I
think we should rename PersistentAttributeFlavor and
PersistentTypeFlavor. PersistentAttributeMapping and
PersistentTypeMapping seem like reasonable names; but the "Persistent"
prefix seems redundant, since Dali "Mappings" are usually "Persistent".
So maybe AttributeMapping and TypeMapping?
- The
subtypes of PersistentTypeFlavor/TypeMapping could be named:
- EmbeddableTypeMapping
- EntityTypeMapping
or EntityMapping (although just plain Entity seems reasonable too)
- MappedSuperclass
(seems OK the way it is)
- NullTypeMapping
And I have no problem with
your renaming these anytime
soon. :-)
And while we're on the issue of names:
- Can we
get rid of the "I" prefix on all our non-EMF interfaces? I don't see
the benefit; but maybe someone can explain it to me.
- Also, I
would like to get rid of the "Wrapper" suffix on many of the classes in
the db plug-in. I've always considered "Wrapper" a term used for implementations not specifications, and these
classes are used as specifications, not as implementations.
Any comments?
Thanks.
Brian
Karen Moore wrote:
Hi all,
I want to propose some
name changes in the ecore
model. I think the flavor concept is not the most intuitive and since
we
call them mappings in the UI anyway, we should probably call them
mappings in
the model. Some of these were named this way because the class name
matches the annotation name, but I don’t think we necessarily have to
do
that. Here are the proposed changes:
Basic ->
BasicMapping
ColumnPersistentAttributeFlavor
-> ColumnMapping
Embedded
->
EmbeddedMapping
GeneratorPersistentAttributeFlavor
-> Not sure about this one
Id ->
IdMapping (I
think Mike Keith was opposed to calling this a mapping, but he had no
other
suggestions for what to call it)
OneToMany
->
OneToManyMapping
OneToOne
->
OneToOneMapping
ManyToMany ->
ManyToManyMapping
ManyToOne ->
ManyToOneMapping
NullPersistentAttributeFlavor
->
InvalidMapping (or maybe NullMapping, but a null mapping is never valid
so
InvalidMapping seems to be more descriptive)
ReferencePersistentAttributeFlavor
->
ReferenceMapping
Transient ->
TransientMapping (this one is a bit odd, any suggestions?)
Version
->
VersionMapping
Should we also rename
PersistentAttributeFlavor and
PersistentTypeFlavor while we’re at it? PersistentAttributeMapping
and PersistentTypeMapping maybe? And what about Entity, Embeddable, and
MappedSuperclass, should those change?
Let me know if you like
these names, have other
suggestions, and if you are opposed to me making the changes now.
Thanks,
Karen
_______________________________________________
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
