<html><body>
<p><font size="4">Andreas states my feelings about "history" much better than I could.</font><br>
<font size="4">I think Stef's scoping idea is an excellent compromise. Please move my vote there.<br>
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.<br>
<br>
Regards,<br>
Sam</font><br>
<br>
<br>
<previous_post_eaten_by_LotusNotes><br>
<br>
>><tt>That is not an argument, one can currently write a method:</tt>...<br>
<br>
I disagree, and that IS an argument. ;-)<br>
Sure, you can write unreadable code in any syntax, but that's not the issue.<br>
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.<br>
<br>
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.<br>
<br>
Its not a trivial change, and it does have much potential for negative impact.<br>
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.<br>
<br>
Is it really worth it? If an application wants to support "alternative syntax", fine, let them. But the trunk?<br>
<br>
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. ;-)<br>
<br>
Regards,<br>
Sam<br>
<br>
</previous_post_eaten_by_LotusNotes><br>
<br>
<br>
Sam S. Adams, IBM Distinguished Engineer, IBM Research<br>
Mobile: 919-696-6064, email: ssadams@us.ibm.com<br>
Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email: Kenndra@us.ibm.com<br>
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>><br>
<br>
<br>
<tt>squeak-dev-bounces@lists.squeakfoundation.org wrote on 03/11/2010 05:32:23 PM:<br>
<br>
> Stéphane Rollandin <lecteur@zogotounga.net> </tt><br>
<tt>> Sent by: squeak-dev-bounces@lists.squeakfoundation.org<br>
> </tt><br>
<tt>> 03/11/2010 05:32 PM</tt><br>
<tt>> <br>
> Please respond to<br>
> The general-purpose Squeak developers list <squeak-<br>
> dev@lists.squeakfoundation.org></tt><br>
<tt>> <br>
> To</tt><br>
<tt>> <br>
> The general-purpose Squeak developers list <squeak-<br>
> dev@lists.squeakfoundation.org></tt><br>
<tt>> <br>
> cc</tt><br>
<tt>> <br>
> Subject</tt><br>
<tt>> <br>
> Re: [squeak-dev] Selectors with underscores</tt><br>
<tt>> <br>
> >> I'm wondering: I don't really know how the people who want underscores<br>
> >> plan to use this, but would it make sense to scope this differently,<br>
> >> i.e., either on a per-class or even a per-method basis?<br>
> ><br>
> > Scoping? Why? A preference is<br>
> > a) simple<br>
> > b) settable by the image owner who is able to decide if he<br>
> > wants to allow it or not (same as with underscores)<br>
> <br>
> scoping makes it possible to load code using selectors with underscores <br>
> in an image where most classes still use underscores for assignments.<br>
> <br>
> I do not see any other way to avoid forcing everybody to review their <br>
> code and check all assignments.<br>
> <br>
> plus, if underscores in methods are mostly useful when interfacing with <br>
> external blobs as Nicolas put it, a per-class scoping makes sense since <br>
> only classes involved with the blob would really need underscored selectors.<br>
> <br>
> so, scoping gives the functionality you want and gives all other people <br>
> confidence that their code won't break. how do other solutions compare ?<br>
> <br>
> Stef<br>
> <br>
> <br>
> <br>
</tt></body></html>