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.
From: dali-dev-bounces@xxxxxxxxxxx
[mailto:dali-dev-bounces@xxxxxxxxxxx] On
Behalf Of Paul Fullbright
Sent: Thursday, February 23, 2006
10:09 AM
To: General Dali EJB ORM developer
discussion.
Subject: Re: [dali-dev] class name
changes
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