[ENH]: FileReference subclasses
Locked
[ENH]: FileReference subclasses
 
Administrator
|
Thoughts? Comments? Opinions?
Issue 6525: [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).
Cheers,
Sean |
Re: [ENH]: FileReference subclasses
|
|
On Sat, Aug 4, 2012 at 9:56 PM, Sean P. DeNigris <[hidden email]> wrote: Thoughts? Comments? Opinions? Hmm, I do not like the idea of having subclasses of references for different kind of files... I believe that things like fileIn for example, or extract zip should be external to the file library...
|
Re: [ENH]: FileReference subclasses
|
|
In reply to this post by Sean P. DeNigris
Will it make more sense to have direct conversion methods i.e.:
someFileReference asSTFileReference specificBehavior. because detecting the file type on it's extension is too unreliable , IMO. On 4 August 2012 21:56, Sean P. DeNigris <[hidden email]> wrote: > Thoughts? Comments? Opinions? > > Issue 6525: [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). > > > > -- > View this message in context: http://forum.world.st/ENH-FileReference-subclasses-tp4643116.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
Re: [ENH]: FileReference subclasses
|
Administrator
|
In reply to this post by Guillermo Polito
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.
Cheers,
Sean |
Re: [ENH]: FileReference subclasses
|
Administrator
|
In reply to this post by Igor Stasenko
I used the file extension in the example because that's what I'm familiar with in other systems. The FileReference subclass could do any checks it wants to prevent false positives (e.g. a .zip file could check that it begins with a local file header signature). Also, this is how file services are already handled in Pharo (browse implementors of #fileReaderServicesForFile:suffix:)
Cheers,
Sean |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |