Status: HumanReviewNeeded
Owner: [hidden email] CC: [hidden email] Labels: Type-Enh Target-Filesystem Milestone-2.0 New issue 6525 by [hidden email]: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 Different types of files have different behaviors. Currently, we need to add all those behaviors (e.g. #fileIn) to FileReference, even though they only make sense with a fraction of instances. I propose that we match the filename against FileReference subclasses. The following is a conversation starter. It works with strings... Usage: '/Users/sean/start.st' asFileReference. "anStFileReference" '/Users/sean/start.unknown' asFileReference. "aFileReference" 'file:///Users/me.st' asUrl asFileReference "not handled by current implementation, will default to aFileReference" For example, I can create a custom .st file subclass, with: StFileReference>>isClassFor: aResolvable (aResolvable isKindOf: String) ifFalse: [ ^ false ]. "just a hack to avoid DNU" ^ aResolvable endsWith: '.st'. Enhancing the following method will catch aString asFileReference, but not e.g. aFileUrl asFileReference: FileSystem>>referenceTo: aResolvable "Answer a reference to the argument from the context of the receiver filesystem. Example: FSFilesystem disk referenceTo: 'plonk.taz'" | referenceClass | referenceClass := FileReference allSubclasses detect: [ :e | e isClassFor: aResolvable ] ifNone: [ FileReference ]. ^ referenceClass fileSystem: self path: (self pathFromObject: aResolvable). Attachments: FileSystem-referenceTo.st 561 bytes StFileReference.st 538 bytes _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #1 on issue 6525 by [hidden email]: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 I don't like this enhancement. IMO, things like filein shouldn't be in a file reference (or a stream). Instead, I would have (CodeLoader readFrom: aStream) execute. (or something like that)... So, I would like more discussion, probably in list more than here :) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Cc: [hidden email] Comment #2 on issue 6525 by [hidden email]: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 @Esteban: Thanks for taking a look. There is a discussion ongoing at http://forum.world.st/ENH-FileReference-subclasses-td4643116.html Guille had the same opinion, to which I responded: My motivation is to make the system live and direct. In the domain of files, an extension signifies a type. As a user, if I have a file type I'm not familiar with, I want to know what kinds of things I can do with it. This approach puts those behaviors in the object that I'm handed back, which represents the file in the Pharo world. I would expect that many of these will in fact simply forward the request to an object external to the file library, but the advantage is that they are reified in the object that the user already has in hand, so they don't have to go searching for that external object. Simply put, yes this behavior should be delegated, *and* there should be a central place where all behaviors related to a file type are accessible to ease discovery from a user perspective. I suspect that the subclasses would use almost 100% delegation... _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: WontFix Comment #3 on issue 6525 by [hidden email]: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 Sorry Sean, after talking with guys here, we come to the conclusion that this is not a good idea :( _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #4 on issue 6525 by [hidden email]: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 @esteban: no apology necessary of course, although I wish the discussion had been carried on in public (e.g. here in the issue) so that I could have participated and better understand the motivations and maybe learn something!! _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Free forum by Nabble | Edit this page |