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.