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: ssadams at us.ibm.com
Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email:
Kenndra at us.ibm.com
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>


squeak-dev-bounces at lists.squeakfoundation.org wrote on 03/11/2010 05:32:23
PM:

> Stéphane Rollandin <lecteur at zogotounga.net>
> Sent by: squeak-dev-bounces at lists.squeakfoundation.org
>
> 03/11/2010 05:32 PM
>
> Please respond to
> The general-purpose Squeak developers list <squeak-
> dev at lists.squeakfoundation.org>
>
> To
>
> The general-purpose Squeak developers list <squeak-
> dev at lists.squeakfoundation.org>
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100312/2addfc02/attachment.htm