[jbosscache-dev] JBCACHE-867

[Galder Zamarreno]

Hehehe, no probs! You've got a point there :)

Now, stop hijacking my threads!! ;)

Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat

IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/

-----Original Message-----
From: Brian Stansberry 
Sent: 27 November 2006 18:03
To: Galder Zamarreno; Manik Surtani; genman at noderunner.net
Cc: jbosscache-dev at lists.jboss.org
Subject: RE: [jbosscache-dev] JBCACHE-867

jbosscache-dev-bounces at lists.jboss.org wrote:
> .... this is a method that could well live in Node as it does
> right now, leaving space for other things in the Cache interface.

(Galder, my apologies in advance for deliberately misinterpreting your post; the above phrasing gave me a chance to say something that's been bugging me for a while...)

I hope we can not have any concept of "available space" in the API.  The API should expose what it needs to expose for users to have the intended functionality as cleanly as possible.  If that means an interface has 100 methods, so be it.  A really large interface may be a sign that refactoring needs to be done or the intended functionality is too broad or whatever, but if in the end the methods are required to do the job, then they should go in and should be located where they make the most sense.

The problem with the old TreeCache API wasn't so much the number of methods as it was the fact that 1) there was no public Interface separate from the internal-use-only public methods and 2) cache configuration wasn't cleanly separated from cache operation.

OK, that's off my chest; climbing down from soapbox now... ;)