On 21.03.11 19:12, "Felix Meschberger" <[email protected]> wrote: >I don't really like this because it adds connotations which might not be >valid and may even indicate wrong usage of the adaptTo method/mechanism. > >The idea of adapTo is to return adapted object in disguise. As such it >is probably irrelevant whether the object returned from adaptTo is the >same everytime or not. In fact, I would even expect to get the same >object each time (if not the same object reference but at least an >"equals" object). > >If a different object is expected on each call to adaptTo, this method >is probably misused as a factory method. > >If there is a general need for such factory functionality, we should >probably devise an explicit factory mechanism.
Well, the borderline is very fuzzy, even for the standard adaptTo cases that come with Sling: On one hand, for example, Resource.adaptTo(InputStream.class) is expected _and_ implemented to return a new input stream every time for nt:file JCR nodes. (Here it is implemented directly in the class and not passed to the Adaptable default implementation that does the caching; but from an API point of view, there is no difference). In other cases, people mainly use adaptTo() to get services / "manager" objects that are tied to the current session using resourceResolver.adaptTo(...), where caching makes a lot of sense. I agree that an adaptTo(Class clazz, boolean doNotCache) seems a bit "ugly", although it is definitely the caller that wants to make the cache/no cache decision. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
