This is a complaint about an actual feature of the tools :)
They automagically convert Squeaks assignment character to the Smalltalk := assignment statement. However it also gets done if the _ occurrs within a string... So importing code that references a database table CUSTOMER_ORDER, will now be CUSTOMER:=ORDER I looked at trying to fix STS, but I think that the effort required to fix the parser, is more than the actual gain? |
Sean,
> This is a complaint about an actual feature of the tools :) > > They automagically convert Squeaks assignment character to the Smalltalk := > assignment statement. > > However it also gets done if the _ occurrs within a string... So importing > code that references a database table CUSTOMER_ORDER, will now be > CUSTOMER:=ORDER I also like the way files with underscores appear in Scamper ;) I think it's one of those things that is not big deal when it clobbers the other guy, hence the lack of attention to it. I keep hoping the unicode changes will give Squeak a proper back arrow that will somehow magically start be used, fixing the problem. > I looked at trying to fix STS, but I think that the effort required to fix > the parser, is more than the actual gain? Which parser? I doubt I can be of any help other than moral support, at least for a while. Somebody created a patch that allows Squeak to compile methods with selectors with underscores in all but the first position. It bugs me that it has not found its way into the mainstream releases. I might be able to dig it up for you, and more power to you if you can get those holding the keys to the update streams to include it. It would be a step in the right direction if they cannot fix the problem via unicode. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
> Which parser? I doubt I can be of any help other than moral support, at
> least for a while. There are actually two places... One in ClassDescription: methodsFor: name stamp: aString "Answer a chunk reader to read and compile method chunks for the receiver to be classified into the method category with the specified <readableString> name. The stamp is ignored. This method is for compatibility with the Squeak fileout format." | useName | useName := name copyReplacing: (self environment at: #Category) separator withObject: $/. ^ChunkReader do: [:chunkString | | methodString | methodString := chunkString copyReplaceAll: '_' with: ':='. self compile: methodString classified: useName] inContext: self atEnd: [] and then in StsSqueakPackageProxy: importMethodsFor: classProxy info: infoLine | tokens methodInfo category methodSource method | methodInfo := self parseMethodInfo: infoLine. methodSource := self nextLineFromStream. [methodSource endsWith: '! !'] whileFalse: [methodSource := methodSource , ' ' , self nextLineFromStream]. methodSource := (methodSource copyFrom: 1 to: methodSource size - 3) copyReplaceAll: 95 asCharacter asString with: ':='. method := (StsCompiledMethodProxy new) methodSource: (self undoubleMarkers: methodSource); methodClass: classProxy. category := methodInfo at: 'category' ifAbsent: []. category isNil ifTrue: [method isPrivate: false] ifFalse: [category = 'private' ifTrue: [method isPrivate: true] ifFalse: [method categoriesString: category , '!']]. classProxy methodDictionary at: method selector put: method (Where 95 asCharacter = $_) As you can see, there is no real source context, it's effectively a straight text replace on any _'s. Might be correct in certain situations (Like the one I've mentioned) I guess one option would be to use the Smalltalk parser, load the source code, perform a rename refactoring on the _ message sends? But HOW do you introduce a refactoring that converts from a message send to an assignment? :) |
Sean,
> As you can see, there is no real source context, it's effectively a straight > text replace on any _'s. Might be correct in certain situations (Like the > one I've mentioned) > > I guess one option would be to use the Smalltalk parser, load the source > code, perform a rename refactoring on the _ message sends? But HOW do you > introduce a refactoring that converts from a message send to an assignment? > :) Depending on your goal, I think Squeak's pretty printing might be able to do it well enough to fix the problem of _ as assignment having been allowed into Squeak's compiler and sources. What they should have done is optionally used _ as a macro for :=, and again optionally had a backspace over $= take out a preceeding $:. That would have given the illusion of single-key assignment they wanted w/o deviating from the language spec. They goofed. As I've always said, open, portable, free, Smalltalk: Squeak has its points. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Sean Malloy-12
This discussion is quite long, so I will fix this in next version of STS
so that it will correctly not convert $_ inside strings. Best regards, David Gorisek Sean Malloy wrote: >>Which parser? I doubt I can be of any help other than moral support, at >>least for a while. > > > > There are actually two places... One in ClassDescription: > > methodsFor: name stamp: aString > "Answer a chunk reader to read and compile method chunks for the receiver > to be classified into the method category with the specified > <readableString> name. > The stamp is ignored. This method is for compatibility with the Squeak > fileout format." > > | useName | > useName := name copyReplacing: (self environment at: #Category) separator > withObject: $/. > ^ChunkReader > do: > [:chunkString | > | methodString | > methodString := chunkString copyReplaceAll: '_' with: ':='. > self compile: methodString classified: useName] > inContext: self > atEnd: [] > > > > and then in StsSqueakPackageProxy: > > importMethodsFor: classProxy info: infoLine > | tokens methodInfo category methodSource method | > methodInfo := self parseMethodInfo: infoLine. > methodSource := self nextLineFromStream. > [methodSource endsWith: '! !'] > whileFalse: [methodSource := methodSource , ' > ' , self nextLineFromStream]. > methodSource := (methodSource copyFrom: 1 to: methodSource size - 3) > copyReplaceAll: 95 asCharacter asString > with: ':='. > method := (StsCompiledMethodProxy new) > methodSource: (self undoubleMarkers: methodSource); > methodClass: classProxy. > category := methodInfo at: 'category' ifAbsent: []. > category isNil > ifTrue: [method isPrivate: false] > ifFalse: > [category = 'private' > ifTrue: [method isPrivate: true] > ifFalse: [method categoriesString: category , '!']]. > classProxy methodDictionary at: method selector put: method > > > (Where 95 asCharacter = $_) > > > > > As you can see, there is no real source context, it's effectively a straight > text replace on any _'s. Might be correct in certain situations (Like the > one I've mentioned) > > I guess one option would be to use the Smalltalk parser, load the source > code, perform a rename refactoring on the _ message sends? But HOW do you > introduce a refactoring that converts from a message send to an assignment? > :) > > > |
> This discussion is quite long, so I will fix this in next version of STS
> so that it will correctly not convert $_ inside strings. > David, Cool! Regards, Sean |
In reply to this post by Schwab,Wilhelm K
Guys - for this kind of thing i think the RB Code Rewriter is perfect...
I'm still trying to get my head around the syntax - some things I easily understand others kind of baffle me... But its pretty well documented here: http://www.stic.org/Smalltalk_Solutions/ss2003/pdf/roberts.pdf and http://www.whysmalltalk.com/events/nfrStS2003%20report.pdf What makes is a bit tricky is the implementation in Dolphin seems to only really show you what its going to do if you use the replace option - in search mode it just shows you the names of methods that match, not the actual method contents that do match. Fortunately replace doesn't actually replace unless you say go ahead, so you can see it working. As you are writing patterns with better context - it can distuinguish between statments, variables, method names etc. A really nice to have (and I'm talking v7) - would be to do something like the XPath/Query tools do - where as you type it starts hiliting what your pattern is doing on some live source code. This would make it much easier to see what you are doing. At the moment, when learning its a bit tedious flipping between windows to see some source, then flipping back to enter your expression and then pressing replace so see what it will do. Tim "Bill Schwab" <[hidden email]> wrote in message news:[hidden email]... > Sean, > >> As you can see, there is no real source context, it's effectively a >> straight text replace on any _'s. Might be correct in certain situations >> (Like the one I've mentioned) >> >> I guess one option would be to use the Smalltalk parser, load the source >> code, perform a rename refactoring on the _ message sends? But HOW do you >> introduce a refactoring that converts from a message send to an >> assignment? :) > > Depending on your goal, I think Squeak's pretty printing might be able to > do it well enough to fix the problem of _ as assignment having been > allowed into Squeak's compiler and sources. What they should have done is > optionally used _ as a macro for :=, and again optionally had a backspace > over $= take out a preceeding $:. That would have given the illusion of > single-key assignment they wanted w/o deviating from the language spec. > They goofed. > > As I've always said, open, portable, free, Smalltalk: Squeak has its > points. > > Have a good one, > > Bill > > -- > Wilhelm K. Schwab, Ph.D. > [hidden email] |
Free forum by Nabble | Edit this page |