Selectors with underscores

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

Selectors with underscores

Torsten Bergmann
>That fundamentally changes the readability of Squeak code and makes all

That is not an argument, one can currently write a method:

   xxxßsoOOollx0001128üäe8
        ^'Unreadble'
 
and thats not readable either.

>future code written that way incompatible with other Smalltalks.

Depends on how you see it. VisualWorks and Smalltalk/MT allow
underscores in selectors as well. Havent tested VAST, Dolphin, GNU, ...

If we dont support it in Squeak we can not load code from
Smalltalks who support it.

What about the following:

We can make it a preference (as it is the case with underscore assignment) and set it to false by default.

So by default the image is clean and people who need it (Glorp for
instance) dont have to patch the image/class Scanner ...

>or maintain your own fork of Squeak

Believe me - there are already enough forks ;)

More opinions please!

Thx
T.







--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Louis LaBrunda
I think VA Smalltalk (VAST) does support it but I never use them.

Lou

On Thu, 11 Mar 2010 16:28:45 +0100, "Torsten Bergmann" <[hidden email]>
wrote:

>>That fundamentally changes the readability of Squeak code and makes all
>
>That is not an argument, one can currently write a method:
>
>   xxxßsoOOollx0001128üäe8
> ^'Unreadble'
>
>and thats not readable either.
>
>>future code written that way incompatible with other Smalltalks.
>
>Depends on how you see it. VisualWorks and Smalltalk/MT allow
>underscores in selectors as well. Havent tested VAST, Dolphin, GNU, ...
>
>If we dont support it in Squeak we can not load code from
>Smalltalks who support it.
>
>What about the following:
>
>We can make it a preference (as it is the case with underscore assignment) and set it to false by default.
>
>So by default the image is clean and people who need it (Glorp for
>instance) dont have to patch the image/class Scanner ...
>
>>or maintain your own fork of Squeak
>
>Believe me - there are already enough forks ;)
>
>More opinions please!
>
>Thx
>T.
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com


Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Bert Freudenberg
In reply to this post by Torsten Bergmann
On 11.03.2010, at 16:28, Torsten Bergmann wrote:
>
>> VisualWorks and Smalltalk/MT allow underscores in selectors as well. Havent tested VAST, Dolphin, GNU, ...
>
> If we dont support it in Squeak we can not load code from Smalltalks who support it.


Supporting them: +1
Using them: -1

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

laza
Ditto!

Nothing prevents uppercase selectors. Same thing.

Alex

On Thu, Mar 11, 2010 at 16:48, Bert Freudenberg <[hidden email]> wrote:

> On 11.03.2010, at 16:28, Torsten Bergmann wrote:
>>
>>> VisualWorks and Smalltalk/MT allow underscores in selectors as well. Havent tested VAST, Dolphin, GNU, ...
>>
>> If we dont support it in Squeak we can not load code from Smalltalks who support it.
>
>
> Supporting them: +1
> Using them: -1
>
> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Randal L. Schwartz
In reply to this post by Bert Freudenberg
>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:

Bert> Supporting them: +1
Bert> Using them: -1

Perhaps a preference, so that Glorp wouldn't have to jump through hoops
to patch the compiler to work, but those who wanted "classic" symbols
could ensure compatibility.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Andreas.Raab
In reply to this post by Torsten Bergmann
On 3/11/2010 7:28 AM, Torsten Bergmann wrote:

> Depends on how you see it. VisualWorks and Smalltalk/MT allow
> underscores in selectors as well. Havent tested VAST, Dolphin, GNU, ...
>
> If we dont support it in Squeak we can not load code from
> Smalltalks who support it.
>
> What about the following:
>
> We can make it a preference (as it is the case with underscore assignment) and set it to false by default.
>
> So by default the image is clean and people who need it (Glorp for
> instance) dont have to patch the image/class Scanner ...

My vote will depend entirely on the backwards compatibility aspect.
What's the current status there? Do you have to switch entire images
between underscore-in-assignment and undersscore-in-selector or can you
scope this more specifically? Can code with underscore assignment still
be loaded?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Sam Adams-2
In reply to this post by Torsten Bergmann

>>That is not an argument, one can currently write a method:...

I disagree, and that IS an argument. ;-)
Sure, you can write unreadable code in any syntax, but that's not the issue.
Supporting underscores in selectors makes a significant change to how the code looks to the eyes, and the habits developed for visually scanning code have to change to accommodate it. THAT affects readability for those code readers who are habituated to normal selectors, and I, for one, have over a quarter century of Smalltalk reading habits that don't change easily. You can argue its not that important, or folks should just change and enjoy it, but it does impact readability.

Another issue is how to adapt underscored selectors if we have a mixed code base and a user sets the preference to non-underscores. I'm only a loyal Squeaker and don't use the other Smalltalks, so perhaps they have solved the problem, but hiding underscores in the tools and then dealing with (re/un)interning symbols, autoconverting to and from camelBack(or something like it), dealing with visual naming conflicts created thereby, etc, starts to sound really messy. Its not at all as simple as the <- vs := support.

Its not a trivial change, and it does have much potential for negative impact.
Perhaps some really clever programmer can make it work *transparently* for those of us who don't prefer it, but I doubt the motivation would be there. Then it would just amount to changing the syntax and tough luck for those who don't appreciate it.

Is it really worth it? If an application wants to support "alternative syntax", fine, let them. But the trunk?

Just 2r11 from a "legacy" Smalltalker who, yes, still uses MVC, albeit running in parallel in a custom VM on a 64-core Tilera chip. ;-)

Regards,
Sam


Sam S. Adams, IBM Distinguished Engineer, IBM Research
Mobile: 919-696-6064, email: [hidden email]
Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email: [hidden email]
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>


Inactive hide details for "Torsten Bergmann" ---03/11/2010 10:29:22 AM--->That fundamentally changes the readability of Squeak "Torsten Bergmann" ---03/11/2010 10:29:22 AM--->That fundamentally changes the readability of Squeak code and makes all


To

[hidden email]

cc


Subject

[squeak-dev] Selectors with underscores

>That fundamentally changes the readability of Squeak code and makes all

That is not an argument, one can currently write a method:

  xxxßsoOOollx0001128üäe8
^'Unreadble'

and thats not readable either.

>future code written that way incompatible with other Smalltalks.

Depends on how you see it. VisualWorks and Smalltalk/MT allow
underscores in selectors as well. Havent tested VAST, Dolphin, GNU, ...

If we dont support it in Squeak we can not load code from
Smalltalks who support it.

What about the following:

We can make it a preference (as it is the case with underscore assignment) and set it to false by default.

So by default the image is clean and people who need it (Glorp for
instance) dont have to patch the image/class Scanner ...

>or maintain your own fork of Squeak

Believe me - there are already enough forks ;)

More opinions please!

Thx
T.







--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter
http://portal.gmx.net/de/go/maxdome01





pic25471.gif (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

radoslav hodnicak
In reply to this post by Andreas.Raab


On Thu, 11 Mar 2010, Andreas Raab wrote:

> My vote will depend entirely on the backwards compatibility aspect. What's
> the current status there? Do you have to switch entire images between
> underscore-in-assignment and undersscore-in-selector or can you scope this
> more specifically? Can code with underscore assignment still be loaded?

the patch for scanner from glorp allows underscore assignment to compile
as long as the underscore has spaces around it, e.g.

test_method
|a|
a _ 3.

compiles


test_method
|a|
a_3

does not

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

radoslav hodnicak

I should add that I personally would rather ban underscore assignment,
than underscores in method names

On Thu, 11 Mar 2010, radoslav hodnicak wrote:

>
>
> On Thu, 11 Mar 2010, Andreas Raab wrote:
>
>> My vote will depend entirely on the backwards compatibility aspect. What's
>> the current status there? Do you have to switch entire images between
>> underscore-in-assignment and undersscore-in-selector or can you scope this
>> more specifically? Can code with underscore assignment still be loaded?
>
> the patch for scanner from glorp allows underscore assignment to compile as
> long as the underscore has spaces around it, e.g.
>
> test_method
> |a|
> a _ 3.
>
> compiles
>
>
> test_method
> |a|
> a_3
>
> does not
>

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Ralph Boland
In reply to this post by Torsten Bergmann
I much prefer arrows to ':=' and will continue to use them
in my private code as long as I can.
However, I accept that Squeak is converting to the use of
':='.  But this conversion only make sense if the intent
is to eventually disallow the use of  '_' (arrow) for
assignment so that it can be used in variable names
and method names.  Thus there must eventually be a
version of Squeak for which an '_' is just an  '_' and
when it arrives I will necessarily use ':=' (I already use
':=' for any code I release).
If you don't agree with me then you should create a fork;
and I will not use your fork.

If one of the characters in range 128-256 were to become
mapped to an  arrow form of assignment though I would
use that.



Regards,

Ralph Boland




--
Had a wife and kids in Florida, Jack (Nicklaus)
Went out for a "ride" but I couldn't get back
As a ten timer being hunted down
OR
When the wife found out who I was knowing (biblically speaking)
I hit a hydrant and I just kept going (till I hit a tree).
...

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Bert Freudenberg
On 11.03.2010, at 18:19, Ralph Boland wrote:

>
> I much prefer arrows to ':=' and will continue to use them
> in my private code as long as I can.
> However, I accept that Squeak is converting to the use of
> ':='.  But this conversion only make sense if the intent
> is to eventually disallow the use of  '_' (arrow) for
> assignment so that it can be used in variable names
> and method names.  Thus there must eventually be a
> version of Squeak for which an '_' is just an  '_' and
> when it arrives I will necessarily use ':=' (I already use
> ':=' for any code I release).
> If you don't agree with me then you should create a fork;
> and I will not use your fork.

Those two issues are independent. '_' is not an arrow, it is an underscore. This is an arrow: '←'.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Stéphane Rollandin
In reply to this post by radoslav hodnicak
> I should add that I personally would rather ban underscore assignment,
> than underscores in method names

sure, but you will probably not go as far as rewrite *my* code, will you
? so please keep backward compatibility.

Stef




Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Stéphane Rollandin
In reply to this post by Torsten Bergmann
> More opinions please!

count me against the idea of using underscores in selectors.

Stef



Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Nicolas Cellier
What about using compilerClass hook and subclass CompilerWithUnderscore.
No need to subclass Parser, just let CompilerWithUnderscore set a flag
(oops,sorry for C verbiage).

Nicolas

2010/3/11 Stéphane Rollandin <[hidden email]>:
>> More opinions please!
>
> count me against the idea of using underscores in selectors.
>
> Stef
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Stéphane Rollandin
> What about using compilerClass hook and subclass CompilerWithUnderscore.
> No need to subclass Parser, just let CompilerWithUnderscore set a flag
> (oops,sorry for C verbiage).

sure

as long as I don't have to scan several thousands of methods to replace
all underscores by hands, it's fine with me.

Stef




Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

K. K. Subramaniam
In reply to this post by Ralph Boland
On Thursday 11 March 2010 10:49:30 pm Ralph Boland wrote:
> I much prefer arrows to ':=' and will continue to use them
> in my private code as long as I can.
> However, I accept that Squeak is converting to the use of
> ':='.  But this conversion only make sense if the intent
> is to eventually disallow the use of  '_' (arrow) for
> assignment so that it can be used in variable names
> and method names.
IMHO, both := and _ are wrong choices. To be consistent with selector
conventions, it should have been =: ( for assign:). But I guess it is too late
now.

Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Eliot Miranda-2


On Fri, Mar 12, 2010 at 9:33 AM, K. K. Subramaniam <[hidden email]> wrote:
On Thursday 11 March 2010 10:49:30 pm Ralph Boland wrote:
> I much prefer arrows to ':=' and will continue to use them
> in my private code as long as I can.
> However, I accept that Squeak is converting to the use of
> ':='.  But this conversion only make sense if the intent
> is to eventually disallow the use of  '_' (arrow) for
> assignment so that it can be used in variable names
> and method names.
IMHO, both := and _ are wrong choices. To be consistent with selector
conventions, it should have been =: ( for assign:). But I guess it is too late
now.

Ha!  The sound of one hand clapping.  Excellent, Subbu!
 

Subbu




Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Stéphane Rollandin
In reply to this post by K. K. Subramaniam
> IMHO, both := and _ are wrong choices. To be consistent with selector
> conventions, it should have been =: ( for assign:). But I guess it is too late
> now.

ah, but _ is not a selector

now if a newly created identifier symbol was automatically bound to a
specific instance of ProtoObject, instead of nil which is the sole
instance of UndefinedObject, then =: could be implemented in ProtoObject
as syntactic sugar for becomeForward:

or am I wrong here ?

Stef



Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

K. K. Subramaniam
In reply to this post by Eliot Miranda-2
On Friday 12 March 2010 11:54:59 pm Eliot Miranda wrote:
> On Fri, Mar 12, 2010 at 9:33 AM, K. K. Subramaniam <[hidden email]>wrote:
> > IMHO, both := and _ are wrong choices. To be consistent with selector
> > conventions, it should have been =: ( for assign:). But I guess it is too
> > late
> > now.
>
> Ha!  The sound of one hand clapping.  Excellent, Subbu!
I missed out a smiley in my signoff. I never expected my tongue-in-cheek
statement to be taken seriously.

;-) .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Selectors with underscores

Yoshiki Ohshima-2
In reply to this post by Stéphane Rollandin
At Fri, 12 Mar 2010 20:01:41 +0100,
Stéphane Rollandin wrote:

>
> > IMHO, both := and _ are wrong choices. To be consistent with selector
> > conventions, it should have been =: ( for assign:). But I guess it is too late
> > now.
>
> ah, but _ is not a selector
>
> now if a newly created identifier symbol was automatically bound to a
> specific instance of ProtoObject, instead of nil which is the sole
> instance of UndefinedObject, then =: could be implemented in ProtoObject
> as syntactic sugar for becomeForward:
>
> or am I wrong here ?

  Hehe.  But if a variable (say an instance variable "x" of an object
"obj") already has a non-nil value, what does that mean?

  In Smalltalk 72, the left arrow was a message to an atom, in deed.
The index finger hand literal object can be sent a string to get an
atom object and it in turn can receive an left arrow message with an
argument.  You can assign atom into another variable.  You can define
the left arrow message for a collection to mean "add" instead assign.
For an instance variable, you can use "'s" message followed by a
string also to get the corresponding atom in the reciver context.

-- Yoshiki

12