Issue 6525 in pharo: [ENH]: FileReference subclasses

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