Naming convention, to avoid collusions

7 views
Skip to first unread message

Alex Snaps

unread,
Aug 5, 2014, 2:57:53 PM8/5/14
to ehcac...@googlegroups.com
Hey all,
While preparing all the doc, tasks and project layout around starting dev around Ehcache3, and as we've decided to make it extend the 107 API, we are running into some serious name collisions here. Obvious example are Cache & CacheManager, but there is more (see below).

So in order to avoid collisions, we probably want to do something about that. Prefix our types? With what? 'Eh'? Find other names for all of these? I'm personally not really thrilled about that. 

Other ideas?  

Really an issue:
javax.cache.Cache$Entry
javax.cache.Cache
javax.cache.CacheException
javax.cache.CacheManager
javax.cache.configuration.CacheEntryListenerConfiguration
javax.cache.configuration.CompleteConfiguration
javax.cache.configuration.Configuration
javax.cache.configuration.MutableCacheEntryListenerConfiguration
javax.cache.configuration.MutableConfiguration
javax.cache.event.CacheEntryCreatedListener
javax.cache.event.CacheEntryEvent
javax.cache.event.CacheEntryEventFilter
javax.cache.event.CacheEntryExpiredListener
javax.cache.event.CacheEntryListener
javax.cache.event.CacheEntryListenerException
javax.cache.event.CacheEntryRemovedListener
javax.cache.event.CacheEntryUpdatedListener
javax.cache.integration.CacheLoader
javax.cache.integration.CacheLoaderException
javax.cache.integration.CacheWriter
javax.cache.integration.CacheWriterException
javax.cache.integration.CompletionListener
javax.cache.integration.CompletionListenerFuture
javax.cache.processor.EntryProcessor
javax.cache.processor.EntryProcessorException
javax.cache.processor.EntryProcessorResult
javax.cache.processor.MutableEntry

Less of an issue:
javax.cache.annotation.* (shouldn't be an issue)
javax.cache.configuration.Factory 
javax.cache.configuration.FactoryBuilder$ClassFactory
javax.cache.configuration.FactoryBuilder$SingletonFactory
javax.cache.configuration.FactoryBuilder
javax.cache.event.EventType
javax.cache.expiry.ExpiryPolicy
javax.cache.management.CacheMXBean
javax.cache.management.CacheStatisticsMXBean
javax.cache.spi.CachingProvider

Alex Snaps

unread,
Aug 5, 2014, 4:05:46 PM8/5/14
to ehcac...@googlegroups.com
Don't care about collusion btw, only about collisions ... 

Chris Dennis

unread,
Aug 6, 2014, 2:43:15 PM8/6/14
to ehcac...@googlegroups.com
I think there are two distinct types of solution needed here:
  1. If we just need to write a concrete impl then I have no problem with just using a prefix.  ‘Eh’ seems the most obvious… I will vote for this as long as it’s pronounced in the Canadian/Fonzie way.
  2. If we’re extending interfaces to form more feature rich interfaces then we need to pick names that express this richer interface.
Make sense?

Chris

--
You received this message because you are subscribed to the Google Groups "ehcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/8a802652-5ce2-4a16-86f8-cddeb6594021%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alex Snaps

unread,
Aug 6, 2014, 2:54:00 PM8/6/14
to ehcac...@googlegroups.com
Y, as of now Cache & CacheManager are just empty interfaces extending the 107 api types. 
Now I expect we'll get more into these... But not sure whether you're thinking will always apply though. But I guess time will tell.
So, for now I leave the conflicts in and go about solving them as we go, i.e. either:
 - getting rid of the interface and use the 107 type instead, where the "default" impl. would be EhSomething
 - Keep the interface, but rename it... somehow.
I'll try that, and get back to you guys when I face some concrete issue then. That's a plan, eh?



For more options, visit https://groups.google.com/d/optout.

Chris Dennis

unread,
Aug 6, 2014, 3:22:29 PM8/6/14
to ehcac...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages