That seems to be anti-uwyn. If I am a developer using the TCTK, the current feature set *only* contains BQ functionality. If and when TCTK makes more functionality available, then it can upgrade the signatures to a new type. Existing code will still compile against this, since the downcast is compatible.
In the case that I the developer wants to use the new features, it's not a burden to change the type I am using, since I am by definition changing how I use the instance. I would say go with BQ if that's all that is supported. Don't try to "look to the future" and make the api more than it is currently. Use the design maxim of cutting away everything until all that is left is what is absolutely necessary. ----- Original Message ----- From: "Geert Bevin" <gbe...@terracottatech.com> To: tc-dev@lists.terracotta.org Sent: Thursday, May 20, 2010 5:37:28 AM GMT -04:30 Caracas Subject: Re: [tc-dev] Toolkit public interface name consistency I meant to write about that, but forgot. There's no specific interface for the clustered queue indeed since there's nothing to add to the standard BlockingQueue. However it might indeed be interesting to have a ClusteredQueue simply extending BlockingQueue so that we can enhance it in the future if that would be needed. On 20 May 2010, at 02:23, Steve Harris wrote: > Not sure if we should have a special interface for blocking queue. Don't have > any specific reasons why other than the fact that we do for a lot of the > other stuff. -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
