Here's a workaround for extracting pieces of a long series of binary
message sends into temps & methods. Example method: giantSpeak Giant new hollar: 'fee' , 'fie' , 'foe' , 'fum' , 'I' , 'smell' , 'the' , 'blood' , 'of' , 'an' , ' Englishman'. Jack new say: 'Do' , 'you' , 'know' , 'an' , 'Englishman' , '?' to: GiantWife new Being a good programmer, I might want to extract 'an', 'Englishman' to another method or temp for reuse in my story. But when I try to select that code & do Extract Method, I get a "Could not extract code from method" error. "Extract to Temporary" grabs the entire series of binary messages, which is wrong. The problem is that the refactoring engine creates a parse tree and does parse tree matching. And basically makes a message node with 'Do', 'you', 'know', 'an' as the receiver #, as the selector 'Englishman' as the argument Then it never matches the selected string. This is not a refactoring from a smalltalk parsing point of view, but I know that semantically my "refactoring" is equivalent. So, the workaround is to recompile the method with ()'s around the part to extract. Then select inside the parens and extract. The RB likes this is much better & complies with your directive. It would be interesting to try to do this automagically if an extraction failed. Insert ()'s in the source at the selection point, and if the resulting source is valid syntax, the match should work and the "refactoring" could continue. See ExtractMethodRefactoring>>extractMethod and step down the long parse tree matching to see what I'm talking about. eric _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
The problem is that you understand the semantics of the , message but
the Refactoring Browser doesn't. The RB doesn't know that the , message is associative. It has no reason to believe that ('a' , 'b') , 'c' is equivalent to 'a' , ('b' , 'c') Smalltalk obviously interprets 'a' , 'b' , 'c' as ('a', 'b') , 'c' You are selecting the 'b' , 'c' part and asking the RB to trust you that the operation is associative. What would you expect the RB to do in this case: a * b + c if you select b + c and ask it to do an extract method? David Buck Simberon Inc. www.simberon.com Eric Winger wrote: > Here's a workaround for extracting pieces of a long series of binary > message sends into temps & methods. Example method: > > giantSpeak > Giant new > hollar: > 'fee' , 'fie' , 'foe' , 'fum' , 'I' , 'smell' , 'the' , > 'blood' , 'of' , > 'an' , ' Englishman'. > Jack new > say: 'Do' , 'you' , 'know' , 'an' , 'Englishman' , '?' > to: GiantWife new > > Being a good programmer, I might want to extract 'an', 'Englishman' > to another method or temp for reuse in my story. But when I try to > select that code & do Extract Method, I get a "Could not extract code > from method" error. "Extract to Temporary" grabs the entire series of > binary messages, which is wrong. > > The problem is that the refactoring engine creates a parse tree and > does parse tree matching. And basically makes a message node with > > 'Do', 'you', 'know', 'an' as the receiver > #, as the selector > 'Englishman' as the argument > > Then it never matches the selected string. > > This is not a refactoring from a smalltalk parsing point of view, but I > know that semantically my "refactoring" is equivalent. > > So, the workaround is to recompile the method with ()'s around the part > to extract. Then select inside the parens and extract. The RB likes > this is much better & complies with your directive. > > It would be interesting to try to do this automagically if an > extraction failed. Insert ()'s in the source at the selection point, > and if the resulting source is valid syntax, the match should work and > the "refactoring" could continue. > > See ExtractMethodRefactoring>>extractMethod and step down the long > parse tree matching to see what I'm talking about. > > eric > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
David Buck <david <at> simberon.com> writes:
> > The problem is that you understand the semantics of the , message but > the Refactoring Browser doesn't. The RB doesn't know that the , message > is associative. It has no reason to believe that > ('a' , 'b') , 'c' > is equivalent to > 'a' , ('b' , 'c') > > Smalltalk obviously interprets > 'a' , 'b' , 'c' as ('a', 'b') , 'c' > > You are selecting the 'b' , 'c' part and asking the RB to trust you that > the operation is associative. > > What would you expect the RB to do in this case: > > a * b + c > > if you select b + c and ask it to do an extract method? > > David Buck Fortunately, you did not choose the more confusing example a + b * c Thinking of non associative operators implemented in base image, found this one: 'a' -> 'b' -> 'c'. Yes, operator creating an Association is not associative. Aren't words usage funny? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by davidbuck
On Jun 26, 2008, at 5:55 PM, David Buck wrote: > The problem is that you understand the semantics of the , message but > the Refactoring Browser doesn't. The RB doesn't know that the , > message is associative. It has no reason to believe that > ('a' , 'b') , 'c' > is equivalent to > 'a' , ('b' , 'c') > > Smalltalk obviously interprets > 'a' , 'b' , 'c' as ('a', 'b') , 'c' > > You are selecting the 'b' , 'c' part and asking the RB to trust you > that the operation is associative. > > What would you expect the RB to do in this case: > > a * b + c > > if you select b + c and ask it to do an extract method? Yes, that's why I quoted the "bug" in my subject line. Your example isn't a refactoring and that's a good point. In my example, the RB does what is the right thing from a st message ordering point of view. But, the key is that I, the programmer, know that this is a true refactoring. Although I can understand why I'm not allowed to do the extraction, I think in this case, the tools should assume I know better (assuming ()'s don't create invalid syntax) and extract as if I know what I'm doing. What might work is for the RB to say: "Hey! This isn't a real refactoring, do you want me to extract anyway?" then I can review the change and proceed based on my knowledge, not the RB's knowledge. Currently I have to do the work myself. By using the ()'s trick in the parsing code, VW could do this. Whether it should is another question. But at least there's an easy workaround. eric > > David Buck > Simberon Inc. > www.simberon.com > > Eric Winger wrote: >> Here's a workaround for extracting pieces of a long series of binary >> message sends into temps & methods. Example method: >> >> giantSpeak >> Giant new >> hollar: >> 'fee' , 'fie' , 'foe' , 'fum' , 'I' , 'smell' , 'the' , >> 'blood' , 'of' , >> 'an' , ' Englishman'. >> Jack new >> say: 'Do' , 'you' , 'know' , 'an' , 'Englishman' , '?' >> to: GiantWife new >> >> Being a good programmer, I might want to extract 'an', >> 'Englishman' to another method or temp for reuse in my story. But >> when I try to select that code & do Extract Method, I get a "Could >> not extract code from method" error. "Extract to Temporary" grabs the >> entire series of binary messages, which is wrong. >> >> The problem is that the refactoring engine creates a parse tree and >> does parse tree matching. And basically makes a message node with >> >> 'Do', 'you', 'know', 'an' as the receiver >> #, as the selector >> 'Englishman' as the argument >> >> Then it never matches the selected string. >> >> This is not a refactoring from a smalltalk parsing point of view, but >> I know that semantically my "refactoring" is equivalent. >> >> So, the workaround is to recompile the method with ()'s around the >> part to extract. Then select inside the parens and extract. The RB >> likes this is much better & complies with your directive. >> >> It would be interesting to try to do this automagically if an >> extraction failed. Insert ()'s in the source at the selection point, >> and if the resulting source is valid syntax, the match should work >> and the "refactoring" could continue. >> >> See ExtractMethodRefactoring>>extractMethod and step down the long >> parse tree matching to see what I'm talking about. >> >> eric >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |