Smalltalk › Squeak › Squeak - Dev

Selectors with underscores

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Torsten Bergmann

Selectors with underscores

Until now we have:

PRO
- Torsten
- Edgar
- Bert
- Alexander
- Matthew
- Keith
- Igor

CONTRA
- Ian Trudel
- Sam

SCOPING
- Andreas (but vote PRO depend on backwards compatibility aspect)
- Stéphane (votes for scoping)

NOT CLEARLY STATED
- Louis
- Randal (vote seem to depend on Preference, which we now have)
- Radoslav (but would rather ban underscore assignment, than
underscores in method names)
- Ralph Boland
- Nicolas

>There's a lot of code that uses at least x_ foo (i.e., no space between >var name and underscore).

With the Preference disabled you have Squeak as it was before and
there should be no problem to load this code. At least if you dont
have packages with "_" selectors. And if thats not enough a simple
lint rule can check that _ selectors are not used in a base/core image.

I dont know about the Etoys codebase that much but is it really relying
on the missing space here?

If not the code can be automatically converted while loading as Matthew
suggested in [1] today. An alternative would be to do the homework
(as with other stuff like #fixTemps and friends) and update the
code when moving to newer Squeak?!

The Refactoring browser also has a nice function to convert _ to := assignments (in the lint tool).

>I'm wondering: I don't really know how the people who want underscores
>plan to use this, but would it make sense to scope this differently,
>i.e., either on a per-class or even a per-method basis?

Scoping? Why? A preference is
a) simple
b) settable by the image owner who is able to decide if he
wants to allow it or not (same as with underscores)

>Per class would be my favorite because in a system where you'd like to
>use underscores globally you'd just have Object
>class>>allowUnderscoreSelectors return true.

You mean this for real? I thought we would clean up the system
instead of putting anything into (already bloated) base classes .... ;)

And is it a class who allows underscore selectors or is it the compiler?

Bye
Torsten

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146419.html
--
GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

Randal L. Schwartz

Re: Selectors with underscores

>>>>> "Torsten" == Torsten Bergmann <[hidden email]> writes:

Torsten> - Randal (vote seem to depend on Preference, which we now have)

I know there's a flag that disables _ as assignment,
but is there also a flag that *enables* _ within an identifier?

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

Nicolas Cellier

Re: Selectors with underscores

2010/3/11 Randal L. Schwartz <[hidden email]>:
>>>>>> "Torsten" == Torsten Bergmann <[hidden email]> writes:
>
> Torsten> - Randal (vote seem to depend on Preference, which we now have)
>
> I know there's a flag that disables _ as assignment,
> but is there also a flag that *enables* _ within an identifier?
>

Not yet.

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

radoslav hodnicak

Re: Selectors with underscores

In reply to this post by Torsten Bergmann

I'm for having underscores in selectors, and a preference seems like a
simple enough solution

On Thu, 11 Mar 2010, Torsten Bergmann wrote:

> Until now we have:
>
> PRO
> - Torsten
> - Edgar
> - Bert
> - Alexander
> - Matthew
> - Keith
> - Igor
>
> CONTRA
> - Ian Trudel
> - Sam
>
> SCOPING
> - Andreas (but vote PRO depend on backwards compatibility aspect)
> - Stéphane (votes for scoping)
>
> NOT CLEARLY STATED
> - Louis
> - Randal (vote seem to depend on Preference, which we now have)
> - Radoslav (but would rather ban underscore assignment, than
> underscores in method names)
> - Ralph Boland
> - Nicolas
>
>> There's a lot of code that uses at least x_ foo (i.e., no space between >var name and underscore).
>
> With the Preference disabled you have Squeak as it was before and
> there should be no problem to load this code. At least if you dont
> have packages with "_" selectors. And if thats not enough a simple
> lint rule can check that _ selectors are not used in a base/core image.
>
> I dont know about the Etoys codebase that much but is it really relying
> on the missing space here?
>
> If not the code can be automatically converted while loading as Matthew
> suggested in [1] today. An alternative would be to do the homework
> (as with other stuff like #fixTemps and friends) and update the
> code when moving to newer Squeak?!
>
> The Refactoring browser also has a nice function to convert _ to := assignments (in the lint tool).
>
>
>> I'm wondering: I don't really know how the people who want underscores
>> plan to use this, but would it make sense to scope this differently,
>> i.e., either on a per-class or even a per-method basis?
>
> Scoping? Why? A preference is
> a) simple
> b) settable by the image owner who is able to decide if he
> wants to allow it or not (same as with underscores)
>
>> Per class would be my favorite because in a system where you'd like to
>> use underscores globally you'd just have Object
>> class>>allowUnderscoreSelectors return true.
>
> You mean this for real? I thought we would clean up the system
> instead of putting anything into (already bloated) base classes .... ;)
>
> And is it a class who allows underscore selectors or is it the compiler?
>
> Bye
> Torsten
>
> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146419.html
> --
> GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
> http://portal.gmx.net/de/go/dsl02
>

Ken G. Brown

Re: Selectors with underscores

Seems like underscores in selectors should be allowed. A single underscore as a selector would mean assignment.

I don't personally like underscores as assignment but they could be allowed by preference but only if they had whitespace either side.

x _ z would be ok equivalent to x := z

And disallow underscore as assignment without whitespace either side.

x_ z or x_z not ok for assignment, they would be taken as selectors.

And encouragement should be provided for preferentially using := going forward.
Seems like a simple enough solution, or am I missing something?

Ken G. Brown

At 11:04 PM +0100 3/11/10, radoslav hodnicak apparently wrote:

>I'm for having underscores in selectors, and a preference seems like a simple enough solution
>
>On Thu, 11 Mar 2010, Torsten Bergmann wrote:
>
>>Until now we have:
>>
>>PRO
>>- Torsten
>>- Edgar
>>- Bert
>>- Alexander
>>- Matthew
>>- Keith
>>- Igor
>>
>>CONTRA
>>- Ian Trudel
>>- Sam
>>
>>SCOPING
>>- Andreas (but vote PRO depend on backwards compatibility aspect)
>>- Stéphane (votes for scoping)
>>
>>NOT CLEARLY STATED
>>- Louis
>>- Randal (vote seem to depend on Preference, which we now have)
>>- Radoslav (but would rather ban underscore assignment, than
>> underscores in method names)
>>- Ralph Boland
>>- Nicolas
>>
>>>There's a lot of code that uses at least x_ foo (i.e., no space between >var name and underscore).
>>
>>With the Preference disabled you have Squeak as it was before and
>>there should be no problem to load this code. At least if you dont
>>have packages with "_" selectors. And if thats not enough a simple
>>lint rule can check that _ selectors are not used in a base/core image.
>>
>>I dont know about the Etoys codebase that much but is it really relying
>>on the missing space here?
>>
>>If not the code can be automatically converted while loading as Matthew
>>suggested in [1] today. An alternative would be to do the homework
>>(as with other stuff like #fixTemps and friends) and update the
>>code when moving to newer Squeak?!
>>
>>The Refactoring browser also has a nice function to convert _ to := assignments (in the lint tool).
>>
>>>I'm wondering: I don't really know how the people who want underscores
>>>plan to use this, but would it make sense to scope this differently,
>>>i.e., either on a per-class or even a per-method basis?
>>
>>Scoping? Why? A preference is
>> a) simple
>> b) settable by the image owner who is able to decide if he
>> wants to allow it or not (same as with underscores)
>>
>>>Per class would be my favorite because in a system where you'd like to
>>>use underscores globally you'd just have Object
>>>class>>allowUnderscoreSelectors return true.
>>
>>You mean this for real? I thought we would clean up the system
>>instead of putting anything into (already bloated) base classes .... ;)
>>
>>And is it a class who allows underscore selectors or is it the compiler?
>>
>>Bye
>>Torsten
>>
>>[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146419.html
>>--
>>GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
>>http://portal.gmx.net/de/go/dsl02

Stéphane Rollandin

Re: Selectors with underscores

In reply to this post by Torsten Bergmann

>> I'm wondering: I don't really know how the people who want underscores
>> plan to use this, but would it make sense to scope this differently,
>> i.e., either on a per-class or even a per-method basis?
>
> Scoping? Why? A preference is
> a) simple
> b) settable by the image owner who is able to decide if he
> wants to allow it or not (same as with underscores)

scoping makes it possible to load code using selectors with underscores
in an image where most classes still use underscores for assignments.

I do not see any other way to avoid forcing everybody to review their
code and check all assignments.

plus, if underscores in methods are mostly useful when interfacing with
external blobs as Nicolas put it, a per-class scoping makes sense since
only classes involved with the blob would really need underscored selectors.

so, scoping gives the functionality you want and gives all other people
confidence that their code won't break. how do other solutions compare ?

Stef

Stéphane Rollandin

Re: Selectors with underscores

In reply to this post by Ken G. Brown

> Seems like underscores in selectors should be allowed. A single underscore as a selector would mean assignment.
>
> I don't personally like underscores as assignment but they could be allowed by preference but only if they had whitespace either side.
>
> x _ z would be ok equivalent to x := z
>
> And disallow underscore as assignment without whitespace either side.
>
> x_ z or x_z not ok for assignment, they would be taken as selectors.
>
> And encouragement should be provided for preferentially using := going forward.
> Seems like a simple enough solution, or am I missing something?

that's fine AFAIC

Stef

keith1y

Re: Selectors with underscores

In reply to this post by Torsten Bergmann

As far as I can see the preference is redundant.

"If you don't want it don' t use it." - I think that covers the
situation as well as it can be covered.

What additional feature does having a preference give you? Apart form
an extra preference?

I agree that the compilerClass hook may be better than an extra
special method. However does the compilerClass hook apply to both
class side and instance side method compilations?

Keith

Sam Adams-2

Re: Selectors with underscores

In reply to this post by Stéphane Rollandin

I think Stef's scoping idea is an excellent compromise. Please move my vote there.
FFI, ORM, etc code is ugly enough, and I would not oppose special syntaxes for special classes, like Slang (restrictions, not syntax in that case) in VMMaker.

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

Stéphane Rollandin ---03/11/2010 05:32:40 PM--->> I'm wondering: I don't really know how the people who want underscores

Stéphane Rollandin <[hidden email]>

Sent by: [hidden email]

03/11/2010 05:32 PM

Please respond to
The general-purpose Squeak developers list <[hidden email]>

To	The general-purpose Squeak developers list <[hidden email]>
cc
Subject	Re: [squeak-dev] Selectors with underscores

>> I'm wondering: I don't really know how the people who want underscores >> plan to use this, but would it make sense to scope this differently, >> i.e., either on a per-class or even a per-method basis? > > Scoping? Why? A preference is > a) simple > b) settable by the image owner who is able to decide if he > wants to allow it or not (same as with underscores) scoping makes it possible to load code using selectors with underscores in an image where most classes still use underscores for assignments. I do not see any other way to avoid forcing everybody to review their code and check all assignments. plus, if underscores in methods are mostly useful when interfacing with external blobs as Nicolas put it, a per-class scoping makes sense since only classes involved with the blob would really need underscored selectors. so, scoping gives the functionality you want and gives all other people confidence that their code won't break. how do other solutions compare ? Stef

pic17892.gif (1K) Download Attachment

Sam Adams-2

Re: Selectors with underscores

In reply to this post by Stéphane Rollandin

Andreas states my feelings about "history" much better than I could.
I think Stef's scoping idea is an excellent compromise. Please move my vote there.
FFI, ORM, etc code is ugly enough, and I would not oppose special syntaxes for special classes, like Slang (restrictions, not syntax in that case) in VMMaker.

Regards,
Sam

<previous_post_eaten_by_LotusNotes>

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

</previous_post_eaten_by_LotusNotes>

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

[hidden email] wrote on 03/11/2010 05:32:23 PM: > Stéphane Rollandin <[hidden email]>
> Sent by: [hidden email] >
> 03/11/2010 05:32 PM
> > Please respond to > The general-purpose Squeak developers list <squeak- > [hidden email]>
> > To
> > The general-purpose Squeak developers list <squeak- > [hidden email]>
> > cc
> > Subject
> > Re: [squeak-dev] Selectors with underscores
> > >> I'm wondering: I don't really know how the people who want underscores > >> plan to use this, but would it make sense to scope this differently, > >> i.e., either on a per-class or even a per-method basis? > > > > Scoping? Why? A preference is > > a) simple > > b) settable by the image owner who is able to decide if he > > wants to allow it or not (same as with underscores) > > scoping makes it possible to load code using selectors with underscores > in an image where most classes still use underscores for assignments. > > I do not see any other way to avoid forcing everybody to review their > code and check all assignments. > > plus, if underscores in methods are mostly useful when interfacing with > external blobs as Nicolas put it, a per-class scoping makes sense since > only classes involved with the blob would really need underscored selectors. > > so, scoping gives the functionality you want and gives all other people > confidence that their code won't break. how do other solutions compare ? > > Stef > > >