Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 4027 invoked by uid 500); 8 Jan 2003 15:43:01 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 3999 invoked from network); 8 Jan 2003 15:43:00 -0000 Message-ID: <3E1C4731.7010007@anyware-tech.com> Date: Wed, 08 Jan 2003 16:43:45 +0100 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: fr, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Defining Source Interfaces References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > >>And as far as code cleanliness is concerned, an "instanceof" test seems >>more OOP to me than a isTraversable() method that tells us if is we have >>the right to use getParent() and getChildren(). With a separate >>interface, these methods do not exist if they do not make sense. >> >This is a point were a not really agree with. If I always have to do instanceof tests and class casts, something is wrong with OOP then in my eyes. > Following Stephen's example, I grep'ed instanceof on the whole 2.1 source base and found... 388 of them ! >Anyway, I think your arguments are better than mine (sniff). > >So, we have a TraversableSource or HierarchicalSource or ...? > > I'm not a native speaker, but the definition of traversable given by dictionary.com makes me prefer hierarchical... Ah, and what about adding an "exists()" method on Source (it's currently on WriteableSource) ? That one makes sense and is really useful, as the current way to know if an URI exists is to try to getInputStream(), which can be heavy. >What do you think about the ModifiableSource in Excalibur? (That should be >the replacement for WriteableSource - please let *me* win this time ;) ) > > Hey, you won on the SourceFactory.release() ! But I don't want to count points or judge anyone/anything. I just want things to be nice, and, well, we sometimes have different feelings about what is nice ;-) I'm not sure about the "Modifiable" name. Maybe I'm biased because it was formerly (in 2.0) used to name something else ? Don't you like "WriteableSource", or "OutputSource" ? Don't know... Whatever its name, it would be good for this interface to have the canCancel() and cancel() that are on WriteableSource. These allow data that has been written to a source to be discarded if something goes wrong. This is especially usefull in pipelines using the SWT for example. About the move() and copy() methods, I don't know if they should be kept in the new incarnation of this interface. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org