[Pharo-project] [ENH]: FileReference subclasses
siguctua at gmail.com
Sun Aug 5 18:55:24 CEST 2012
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 <sean at clipperadams.com> wrote:
> Thoughts? Comments? Opinions?
> Issue 6525: [ENH]: FileReference subclasses
> 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...
> '/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
> ^ 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
> 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.
More information about the Pharo-project