Re: [hibernate-dev] 6.0 proposal - CollectionTuplizer

As part of removing most Type sub-types we are left with the question of how to handle the role served by CollectionType. Andrea and I came up with a proposal that not only serves that purpose but also allows a level of customization we have so far not supported but which has been asked for a few times (mostly as part of framework/language integration into Hibernate; Ceylon, etc). Here is the proposal: /** * Encapsulates collection type specific behavior/information * <p/> * NOTE : the name "tuplizer" was chosen as this really serves * same logical purpose as the entity and component tuplizers * do entities and components respectively. */ interface CollectionTuplizer<C> { /** * Access to the type of the collection. This * is expected to be an interface. Used to create * a registry against which we can resolve the * reflected attribute type. E.g. an attribute * defined as `List` would be resolved to the * CollectionTuplizer that deals with lists */ Class<C> getCollectionJavaType(); /** * Create an empty instance of the collection wrapper */ PersistentCollection<C> create(int anticipatedSize); /** * Wrap an existing "raw" view of the collection */ PersistentCollection<C> wrap(Object rawCollection); /** * Creates the representation of this plural attribute * according to the runtime domain model view. */ <O> PluralPersistentAttribute<O,C,?> generatePluralAttribute(); // anytihng else? element comparator, etc? } Thoughts? Suggestions?