--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Mon, 16 Feb 2004, Matt Benson > <[EMAIL PROTECTED]> wrote: > > > is it currently possible to use a type as its own > class if > > available, then adapt if possible instead? > > I'm not sure I follow you here. My guess is that > the answer is no, > could be yes, though. 8-)
My thinking here was if there existed two file collection abstractions, say o.a.t.a.types.AbstractFileSet and o.a.t.a.types.maybenewpackagehere.NewFileSetInterface, each could be <typedef>d to adapt to the other, so that the maximum number of Tasks could use both with no change in functionality as Tasks were converted to use the new interface. But the adaptation would only take place after the true class had been tried. I haven't yet studied the introspection mechanisms in sufficient depth to be sure what behavior would currently be chosen, but based on what I do know I would not be terribly surprised if this either works already or comes to a very small change. > > > One of the first things I had considered this > might imply, and > > perhaps fairly convenient to implement, is > pluggable FileUtils > > implementations. Since a FileUtils object is > obtained by a static > > call, this might not be too bad. Does anyone have > any ideas on > > nice, clean ways an antlib might plug into > something like this? > > Depends on how you want to go with it. It sounds as > if you wanted the > antlib to influence all other tasks, even those > belonging to a > different antlib, this sounds dangerous. > I suppose that is what I was saying, in a way... I am not sure how a each plug-in implementation's behavior would be validated against the core, but, aside from being quite a bit "bigger", allowing the user to choose his file-handling implementation seems akin to allowing to choose from regular expression implementations. > commons-vfs > > > already done it, but it also becomes a dependency, > > most likely, and a sandbox dependency at that... > > and to top it, one where development seems to have > stopped right now. > That is kind of bad. But based on its documentation alone, commons-vfs does seem to allow clients to add custom "protocols" (my pet one is "property:"). If this works, then anyone could develop and submit support for more protocols. So maye no project-led development is required. Is there a complete implementation of anything else that has the functionality and flexibility we need? Also, you mentioned not wanting to accumulate dependencies... but that IS the purpose of the commons, is it not? And at least you can pick and choose among the commons components. I am not necessarily in favor of adding vfs or anything else as a core dependency, but there are only so many ways we can go. I for one would be delighted to hear any ideas that will work. -Matt __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
