On Sat, Aug 4, 2012 at 9:56 PM, Sean P. DeNigris <[email protected]>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. > >
