Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top