On Wed, 21 Mar 2007, Matt Benson <[EMAIL PROTECTED]> wrote: > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> We would want to have a FileRessource remain a FileRessource even >> when mapping them - same for the other subclasses of Ressource. >> Some kind of factory would be needed and using an intferface >> instead of creating yet another subclass of Ressource (or a couple >> of them) might help. > > Are you suggesting dynamic proxies here? Well, at least I thought about them, even though I don't have any experience with cglib or any other existing library. > I think this implicit RC mapping question does after > all differ from Alexey's request; I don't remember Alexey's request in detail, so you are probably right. > however I let myself misunderstand the direction of this thread and > be led down the path of composing a large diatribe on THAT suject, OK. > Wrt explicitly mapped resourcecollections I think what is needed is > a well-known syntax specification for specifying a string > representation of [resource-type][String to pass to constructor] > e.g. "file?/foo/bar.baz", "url?http://www.apache.org";, "string?blah > blah blah". Ahh, that discussion 8-) > One may recall this as something I've been after for awhile--I > consider it the "next step" for resource handling in Ant. For code > compartmentalization we could probably add the code to generate a > Resource from a String to ResourceUtils, but IH would know how to > use e.g. RU.getResource(Project, String) to set Resource attributes > (for BC, FileResource would be the default). I don't think there is anything wrong with that. We deferred it until after Ant 1.7.0 but I don't see any reason to not implement it now. I'll cut the rest of this and respond to it separately in a fresh thread (tomorrow, I guess, need to make breakfast for my kids now). > Back to our regularly scheduled content... >> >> > But to do this with an interface means its consumers would have >> > to check for it explicitly; put another way, that all resource >> > consumers would not immediately benefit. If we implemented the >> > name-mapping behavior such that it simple overrode getName(), the >> > consequent question is why have an interface at all? >> >> The interface could provide access to the original name and >> override getName(). > > I think I knew that's what you meant... again, to > implement MappedResource while remaining a > FileResource, dynamic... subclasses? Eek! Or just have a factory that returns static/anonymous? subclasses of FileRessource and others. I want to avoid that we add more concrete classes to the ressource mix to make things worse. > Surely we can't go there... maybe we'd better rethink the > "instanceof FileResource" idiom instead, e.g. > isFilesystemResource()? Or throw in an interface that contains getFile() and is implemented by FileRessource - and modify the "instanceof FileResource" idiom to "instanceof that new interface". > But if we simply added isFilesystemResource() to Resource, couldn't > a MappedResource just delegate to the original? Might that be > enough? You'd also need to delegate getFile if that was possible. Or getArchive in case of an ArchiveRessource or ... >> But before you dare to override getName, better check usage >> patterns in existing tasks. I wouldn't be surprised if we still >> had tasks that used "new File(parentDir, ressource.getName())" or >> something similar and expected the file to exist. > > I don't know. I don't think Resources were in extremely wide use > until the 1.7 branch, Probably not. > and again, this is the type of problem that is extremely unlikely to > simply arise at runtime--the build writer should have plenty of time > to figure out "doh, <foo> doesn't seem to support X resource...". I > think adequate disclaimers and warnings should suffice in these > cases. Yes, this might work. Let's be careful, still. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
