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