Re: [Pharo-project] About (backwards) Compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

Eliot Miranda-2



On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

Igor Stasenko
On 22 December 2012 19:04, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <[hidden email]>
> 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).
>


yes, i want string math, because at the end, everything you type into
machine is strings, so having objects, classes or compiled methods
seems like overcomplication, when you can do the same by just using
stings..
We definitely should reconsider "everything is an object" postulate,
instead we should postulate "everything is string",
otherwise smalltalk will never be a successful platform like
javascript/perl etc.

oh, yes, and while we're changing that, please add the 'math' precedence rules,
because my math teacher is the school told me that this is the only
right way they should be processed,
oh, and at last, lets use curly braces syntax because it is sooo convenient.
;)

> I hope Squeak integrates FileSystem in 4.4 for 4.5.
> --
> best,
> Eliot


--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

Frank Shearar-3
On 22 December 2012 19:04, Igor Stasenko <[hidden email]> wrote:

> On 22 December 2012 19:04, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>> On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <[hidden email]>
>> 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).
>>
>
>
> yes, i want string math, because at the end, everything you type into
> machine is strings, so having objects, classes or compiled methods
> seems like overcomplication, when you can do the same by just using
> stings..
> We definitely should reconsider "everything is an object" postulate,
> instead we should postulate "everything is string",
> otherwise smalltalk will never be a successful platform like
> javascript/perl etc.
>
> oh, yes, and while we're changing that, please add the 'math' precedence rules,
> because my math teacher is the school told me that this is the only
> right way they should be processed,
> oh, and at last, lets use curly braces syntax because it is sooo convenient.
> ;)

But don't forget to preserve the fact that '1' + 1 is not the same as 1 + '1' !

frank

>> I hope Squeak integrates FileSystem in 4.4 for 4.5.
>> --
>> best,
>> Eliot
>
>
> --
> Best regards,
> Igor Stasenko.
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

Andreas.Raab
In reply to this post by Igor Stasenko
Igor Stasenko wrote
yes, i want string math, because at the end, everything you type into
machine is strings, so having objects, classes or compiled methods
seems like overcomplication, when you can do the same by just using
stings..
We definitely should reconsider "everything is an object" postulate,
instead we should postulate "everything is string",
otherwise smalltalk will never be a successful platform like
javascript/perl etc.

oh, yes, and while we're changing that, please add the 'math' precedence rules,
because my math teacher is the school told me that this is the only
right way they should be processed,
oh, and at last, lets use curly braces syntax because it is sooo convenient.
Could you move your trolling attempts to the pharo list please?

Thanks,
  - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

Igor Stasenko
On 23 December 2012 11:16, Andreas.Raab <[hidden email]> wrote:

> Igor Stasenko wrote
>> yes, i want string math, because at the end, everything you type into
>> machine is strings, so having objects, classes or compiled methods
>> seems like overcomplication, when you can do the same by just using
>> stings..
>> We definitely should reconsider "everything is an object" postulate,
>> instead we should postulate "everything is string",
>> otherwise smalltalk will never be a successful platform like
>> javascript/perl etc.
>>
>> oh, yes, and while we're changing that, please add the 'math' precedence
>> rules,
>> because my math teacher is the school told me that this is the only
>> right way they should be processed,
>> oh, and at last, lets use curly braces syntax because it is sooo
>> convenient.
>
> Could you move your trolling attempts to the pharo list please?
>
First. It was not trolling attempt, but sarcasm attempt. :)

Second. The topic was originally from pharo list.
I don't know why people moved discussion it on squeak-dev list.
I just replying.
But thanks for reminder that i am not welcome here anymore.


> Thanks,
>   - Andreas
>

--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

David T. Lewis
On Sun, Dec 23, 2012 at 03:39:28PM +0100, Igor Stasenko wrote:

> On 23 December 2012 11:16, Andreas.Raab <[hidden email]> wrote:
> > Igor Stasenko wrote
> >> yes, i want string math, because at the end, everything you type into
> >> machine is strings, so having objects, classes or compiled methods
> >> seems like overcomplication, when you can do the same by just using
> >> stings..
> >> We definitely should reconsider "everything is an object" postulate,
> >> instead we should postulate "everything is string",
> >> otherwise smalltalk will never be a successful platform like
> >> javascript/perl etc.
> >>
> >> oh, yes, and while we're changing that, please add the 'math' precedence
> >> rules,
> >> because my math teacher is the school told me that this is the only
> >> right way they should be processed,
> >> oh, and at last, lets use curly braces syntax because it is sooo
> >> convenient.
> >
> > Could you move your trolling attempts to the pharo list please?
> >
> First. It was not trolling attempt, but sarcasm attempt. :)
>
> Second. The topic was originally from pharo list.
> I don't know why people moved discussion it on squeak-dev list.
> I just replying.
> But thanks for reminder that i am not welcome here anymore.

Igor: You are welcome here.

Andreas: It was just a joke, not trolling.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About (backwards) Compatibility

Bert Freudenberg
In reply to this post by Igor Stasenko

On 2012-12-23, at 15:39, Igor Stasenko <[hidden email]> wrote:

> On 23 December 2012 11:16, Andreas.Raab <[hidden email]> wrote:
>> Igor Stasenko wrote
>>> yes, i want string math, because at the end, everything you type into
>>> machine is strings, so having objects, classes or compiled methods
>>> seems like overcomplication, when you can do the same by just using
>>> stings..
>>> We definitely should reconsider "everything is an object" postulate,
>>> instead we should postulate "everything is string",
>>> otherwise smalltalk will never be a successful platform like
>>> javascript/perl etc.
>>>
>>> oh, yes, and while we're changing that, please add the 'math' precedence
>>> rules,
>>> because my math teacher is the school told me that this is the only
>>> right way they should be processed,
>>> oh, and at last, lets use curly braces syntax because it is sooo
>>> convenient.
>>
>> Could you move your trolling attempts to the pharo list please?
>>
> First. It was not trolling attempt, but sarcasm attempt. :)

I thought it was funny :)

> Second. The topic was originally from pharo list.
> I don't know why people moved discussion it on squeak-dev list.
> I just replying.
> But thanks for reminder that i am not welcome here anymore.


Nah, you are most certainly welcome. Andreas was just misreading you.

- Bert -