On Sat, Aug 4, 2012 at 9:56 PM, Sean P. DeNigris <sean@clipperadams.com>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...
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.