whew, I'll try this: :) --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 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. Yep, me neither, but as I think I wrote and you snipped from what I've seen you earn what you get from cglib. In case that doesn't come across well to non-native speakers (or otherwise; sometimes nobody understands me) I am saying I think cglib deserves respect from a functional standpoint and it can and will do a lot for you (as evidenced by Spring and Hibernate), but it would take a lot of research on your part to understand how to make cglib do what you want it to do. Maybe I don't have a firm enough grounding in class structures, etc. though and it's not as bad as I think, or maybe I'm just an idiot. Plus it's been awhile. In any event, when I looked at it I ran. ;) > > > 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. > Basically a mapped fileset... I think we could extrapolate mapped resource collection, and I think the string resource representation could take this a long way. [SNIP] > 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). As you say, another discussion. Hope your kids were nutritiously fed and I look forward to your separate email... ;) > > > 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". That gives me a nice comfy feeling. If we simply mandate that this type of Resource classification should always be interface-defined (we probably should have done this from the beginning and I'll accept at least 70% of the responsibility for that), we can use JDK1.3 proxies and avoid cglib, the very mention of which made me whimper in fear due to its high learning curve and the fact that it would be a dependency that would probably have been mandatory, at least for all practical purposes. > > > 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 ... All moot I think simply by saying that getFile() is defined in an interface. Ahh... Another cool thing seems to be that we could provide some kind of ResourceCollection that could proxy the resources from another collection but provide their content in files even for non-file resources for compatibility with things that required files. This would probably take some doing to make it actually useful, but might be interesting. > > >> 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. Okay. :) -Matt > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
