Stéphane Rollandin wrote
>scoping ... >... >... Thanks for the long explaination - but I KNOW all that and have FULLY understood what Andreas meant. But my "Scoping? Why?" question was more a - "Why should we do that, when other Smalltalk dialects dont?". - "There is no scoping for this in others Smalltalk, so WHY should Squeak artificially have it." - "Why would we limit Squeak to allow it only to specific classes?" - "Why should we go an own route again here?" I stand my original suggestion/changeset which a) either disallows selectors with underscore for the whole image -> turn preference off b) -> turn preference on fully allows one to file in and use code from other Smalltalk systems or implement the use case where you need an underscore in a selector in whatever class you require This would reduce the balkanization of Smalltalk (see [1]) a little bit and allow for easy exchange and freedom in implementation. If one really mixes "underscore assignment" and "underscores in selectors" then I would rather see x_ 1 converted to x := 1 or at least x _ 1 Hey it's all code and changeable! Especially when we have tools like RefactoringBrowser, Rewrite Tool, ... and a dynamic system that is able to tell us where such code exists. Bye T. [1] http://www.threeriversinstitute.org/blog/?p=466 -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 |
On 3/11/2010 3:51 PM, Torsten Bergmann wrote:
> But my "Scoping? Why?" question was more a > > - "Why should we do that, when other Smalltalk dialects dont?". > - "There is no scoping for this in others Smalltalk, so WHY should > Squeak artificially have it." > - "Why would we limit Squeak to allow it only to specific classes?" > - "Why should we go an own route again here?" Isn't it obvious? Because Squeak has a history. And it's worth discussing if we want to break that history or not, and to what extent. "All the other Smalltalks" do not use underscores as assignments so all of the above questions are besides the point. This discussion is about Squeak and should be about Squeak. Scoping provides a relatively easy way out since it allows you to benefit from using underscores in selectors while allowing others to use underscores as assignments in their respective subsystems. BTW, just for the records, my *personal* opinion is expressed in Croquet: Forbid underscore altogether. > I stand my original suggestion/changeset which > > a) either disallows selectors with underscore for the whole image > -> turn preference off > > b) -> turn preference on > fully allows one to file in and use code from other Smalltalk > systems or implement the use case where you need an underscore > in a selector in whatever class you require > > This would reduce the balkanization of Smalltalk (see [1]) a little > bit and allow for easy exchange and freedom in implementation. > > If one really mixes "underscore assignment" and "underscores in selectors" > then I would rather see x_ 1 converted to x := 1 or at least x _ 1 > > Hey it's all code and changeable! Especially when we have tools > like RefactoringBrowser, Rewrite Tool, ... and a dynamic system > that is able to tell us where such code exists. Having a working implementation of a tool that that automatically rewrites underscores into assignments on fileIn and MC package install would go a VERY long way to alleviate my concerns. In fact, even a prototype that illustrates the concept might be enough for now because it may encourage others to help. Cheers, - Andreas |
On 12 March 2010 05:00, Andreas Raab <[hidden email]> wrote:
> On 3/11/2010 3:51 PM, Torsten Bergmann wrote: >> >> But my "Scoping? Why?" question was more a >> >> - "Why should we do that, when other Smalltalk dialects dont?". >> - "There is no scoping for this in others Smalltalk, so WHY should >> Squeak artificially have it." >> - "Why would we limit Squeak to allow it only to specific classes?" >> - "Why should we go an own route again here?" > > Isn't it obvious? Because Squeak has a history. And it's worth discussing if > we want to break that history or not, and to what extent. > > "All the other Smalltalks" do not use underscores as assignments so all of > the above questions are besides the point. This discussion is about Squeak > and should be about Squeak. Scoping provides a relatively easy way out since > it allows you to benefit from using underscores in selectors while allowing > others to use underscores as assignments in their respective subsystems. > > BTW, just for the records, my *personal* opinion is expressed in Croquet: > Forbid underscore altogether. > >> I stand my original suggestion/changeset which >> >> a) either disallows selectors with underscore for the whole image >> -> turn preference off >> >> b) -> turn preference on >> fully allows one to file in and use code from other Smalltalk >> systems or implement the use case where you need an underscore >> in a selector in whatever class you require >> >> This would reduce the balkanization of Smalltalk (see [1]) a little >> bit and allow for easy exchange and freedom in implementation. >> >> If one really mixes "underscore assignment" and "underscores in selectors" >> then I would rather see x_ 1 converted to x := 1 or at least x _ 1 >> >> Hey it's all code and changeable! Especially when we have tools >> like RefactoringBrowser, Rewrite Tool, ... and a dynamic system >> that is able to tell us where such code exists. > > Having a working implementation of a tool that that automatically rewrites > underscores into assignments on fileIn and MC package install would go a > VERY long way to alleviate my concerns. In fact, even a prototype that > illustrates the concept might be enough for now because it may encourage > others to help. > > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. FixUnderscores.st (4K) Download Attachment |
On 3/11/2010 7:16 PM, Igor Stasenko wrote:
>> Having a working implementation of a tool that that automatically rewrites >> underscores into assignments on fileIn and MC package install would go a >> VERY long way to alleviate my concerns. In fact, even a prototype that >> illustrates the concept might be enough for now because it may encourage >> others to help. >> > Are you talking about this one? (see attachment). Close, but no cigar. The problem with FixUnderscores is that it requires the code to be loaded under the old rules first. If you can't load the old code FixUnderscores is completely pointless. That's why I'm saying something that illustrates rewriting DURING fileIn / package load is so valuable. Basically, what I'm asking for is this: What process does someone have to go through when they file out code from Squeak 2.0 and into Squeak 4.1? If it just breaks, I'd not be happy. If it asks you for example "hey, this looks like old code using underscore assignments, would you like me to convert this to the current style?" I'd take it. BTW, there are other approaches that would make me similarly happy, this is just an example. I'm looking for a consistent story where we can tell people "oh, you got code from Squeak 2.8, here is what you do: ...." Cheers, - Andreas |
In reply to this post by Torsten Bergmann
> If one really mixes "underscore assignment" and "underscores in selectors" > then I would rather see x_ 1 converted to x := 1 or at least x _ 1 sure, but that's not so easy: > Hey it's all code and changeable! Especially when we have tools > like RefactoringBrowser, Rewrite Tool, ... and a dynamic system > that is able to tell us where such code exists. those tools will break the methods formatting and change the methods date and authors initials. that's a lot of metainfo lost (especially formatting: I personnally can't parse the result of the prettyprinter) so, as usual when I object to something, I'm not driven by ideological positions; I'm only concerned about the amount of work the proposed change is going to force me to do on my code. here, in case the underscore assignment becomes fuly illegal, it looks like a lot of work. cheers, Stef |
In reply to this post by Andreas.Raab
On Fri, Mar 12, 2010 at 4:00 AM, Andreas Raab <[hidden email]> wrote:
> On 3/11/2010 3:51 PM, Torsten Bergmann wrote: >> >> But my "Scoping? Why?" question was more a >> >> - "Why should we do that, when other Smalltalk dialects dont?". >> - "There is no scoping for this in others Smalltalk, so WHY should >> Squeak artificially have it." >> - "Why would we limit Squeak to allow it only to specific classes?" >> - "Why should we go an own route again here?" > > Isn't it obvious? Because Squeak has a history. And it's worth discussing if > we want to break that history or not, and to what extent. > > "All the other Smalltalks" do not use underscores as assignments so all of > the above questions are besides the point. This discussion is about Squeak > and should be about Squeak. Scoping provides a relatively easy way out since > it allows you to benefit from using underscores in selectors while allowing > others to use underscores as assignments in their respective subsystems. > > BTW, just for the records, my *personal* opinion is expressed in Croquet: > Forbid underscore altogether. > >> I stand my original suggestion/changeset which >> >> a) either disallows selectors with underscore for the whole image >> -> turn preference off >> >> b) -> turn preference on >> fully allows one to file in and use code from other Smalltalk >> systems or implement the use case where you need an underscore >> in a selector in whatever class you require >> >> This would reduce the balkanization of Smalltalk (see [1]) a little >> bit and allow for easy exchange and freedom in implementation. >> >> If one really mixes "underscore assignment" and "underscores in selectors" >> then I would rather see x_ 1 converted to x := 1 or at least x _ 1 >> >> Hey it's all code and changeable! Especially when we have tools >> like RefactoringBrowser, Rewrite Tool, ... and a dynamic system >> that is able to tell us where such code exists. > > Having a working implementation of a tool that that automatically rewrites > underscores into assignments on fileIn and MC package install would go a > VERY long way to alleviate my concerns. In fact, even a prototype that > illustrates the concept might be enough for now because it may encourage > others to help. > > Cheers, > - Andreas > > I this tool also could change method categories to extensions and class categories to a single package it would rock ! It could even be interactive so one could decide case by case what to do with each class, method and "underscore in case of literal". Karl |
We can do that, with the cuis process, we have refactored the fileIn/fileOut code so we are getting this level of control. The standard fileIn cant even handle errors ort missing classes Keith |
Free forum by Nabble | Edit this page |