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

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:
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

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 -

Ditto!

Nothing prevents uppercase selectors. Same thing.

Alex

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

>>>>> "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

On 3/11/2010 7:28 AM, Torsten Bergmann 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?

Cheers,
   - Andreas

>>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>>


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

"Torsten Bergmann" <[hidden email]> Sent by: [hidden email] 03/11/2010 10:28 AM Please respond to The general-purpose Squeak developers list <[hidden email]>

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

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

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

On Thu, 11 Mar 2010, radoslav hodnicak 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.

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).
...

On 11.03.2010, at 18:19, Ralph Boland wrote:
Those two issues are independent. '_' is not an arrow, it is an underscore. This is an arrow: '←'.

- Bert -

> 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

> More opinions please!

count me against the idea of using underscores in selectors.

Stef

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
>
>
>
>

> 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

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

> 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

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

At Fri, 12 Mar 2010 20:01:41 +0100,
Stéphane Rollandin wrote:
  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