On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
H. Hirzel wrote
As Chris points out, the difference is minimal.
Sean, it looks like you need better examples to show how you perceive the benefits of the FileSystem design
While you ignored the point of my followup post, which is that beauty and simplicity lead to more than the sum of a few keywords, here are a few basic examples...
Example #1: file := FileDirectory directoryEntryFor: '/path/to/file'. FileDirectory extensionFor: file name.
vs.
file2 := '/path/to/file' asFileReference. file2 extension.
#2: (FileDirectory on: 'path') entryAt: 'nohup.out'. vs. 'path' asFileReference / 'filename'
"Most operations routed through one massive FD class" vs. "immediate access to the domain object you want"; not to mention the appreciated absence of parens.
No difference??
But with
String methods for *FileSystem-utilities / aPath ^self asFileReference / aPath you get 'path' / 'filename' and that's *really* nice. Does anyone think that '123' / '45' is good?? This is a compromise: / arg self size = 0 ifTrue: [self error: 'cannot coerce the empty string]. ^('+-01234456789' incudes: self first) ifTrue: [arg adaptToString: self andSend: #/] ifFalse: [self asFileReference / arg] the issue here being whether FileSystem wants '.profile' or '.hg' et al or math wants '.123'. If FileSystem provides path-name checking then the above could include a specific legality check instead of the naive discrimination. Personally I find the prospect of a concise file scripting api much more appealing than lazy numeric conversion. The absence of the former is why so much of my life involves bash scripts. The latter isn't necessary if one starts off with numbers in the first place, and being literals they're as easy, no, easier than denoting numbers using strings (1 + 1 is shorter than '1' + 1). I hope Squeak integrates FileSystem in 4.4 for 4.5. -- best, Eliot