Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Extract Method Bugs and Implicit Return

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
cbranch Posted - Jun 06 2007 : 2:07:51 PM
Sorry if this is a known issue, I couldn't find this on a cursory search of the forums. Also this is all with VAX 1557.

I frequently want to extract functions that have a single variable which I want to be the implied return value.


void foo()
{
   int a;
   a = 1 + 2;
   return a;
}

I would like to refactor the line 'a = 1 + 2' and have something like this:


void foo()
{
   int a;
   a = addFunction();
   return a;
}

int addFunction()
{
   return 1 + 2;
}

Unfortunately what I get is this:


void foo()
{
   int a;
   a = addFunction(a);
   return a;
}

int addFunction( int a )
{
   a = 1 + 2;	return a;
}

Which of course make sense if VAX has no way of knowing that 'a' is only used as an L-Value within the new function. If I select '1 + 2;' I get an invalid method. If I select '1 + 2' but not the trailing semicolon I get the correct method. The trailing semicolon issue seems like a bug to me. However ultimately it would be nice to properly identify 'a' as simply the return L Value and removed.

A small aside:
An alternative valid implementation could be:


void addFunction( int& a )
{
   a = 1 + 2;
}

This form seems to be better at preserving the behavior of the original function. And it doesn't require the variable be copiable, or if there is any secondary costs/operations that occur due to the copy.

One motivation to do implicit returns is that it may be required to generate valid code. One way to strongly suggest that the user intends for a return would be to include the declaration of the variable intended to be returned in the extracted function. In my example, both lines 'int a;' and 'a = 1 + 2;' Which would result in VAX realizing that since the symbol 'a' is used after the extraction a new symbol 'a' must be created and assigned via the return of the new function.


void foo()
{
 /* Lines refactored
     int a;
     a = 1 + 2;
 */
 
 // New VAX generated code
    int a = addFunction();

 // Original Code
   return a;
}

int addFunction()
{
   int a;
   a = 1 + 2;
   return a;   
}

Currently VAX generates uncompilable code. This:

int foo()
{
   addFunction();
   return a;
}

void addFunction()
{
   int a;
   a = 1 + 2;
}


VAX generates some truly strange code if you miss the last semicolon. Extracting 'int a' and 'a = 1 + 2' generates:

bool addFunction()
{
   return int a;
   a = 1 + 2;
}

Which of course doesn't compile.

It would be nice if VAX would check if the extract would actually generate working code simply by checking to see if the extracted symbols are used after the extracted section. If only one symbol is used, it can be implicitly defined as being assigned by the return. Multiple symbols may well be impossible to properly handle in a general sense (except for simple value types). A warning or something could be nice.(configurable on/off of course).


Regards,
Colin Branch
1   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Jun 06 2007 : 2:23:51 PM
The parameter passing and returning, we know we need Extract Method to pass things by reference more often:

case=1152

I am not sure if this change, when it is made, will help here or not. The current effect is actually described here:

http://www.wholetomato.com/products/features/extractMethod.asp

in the parameters section. Remember that when you move past "int" and onto complex types things are not always so simple.


Selecting the declaration of the variable, by design VA assumes that if you have selected the declaration then you are extracting all instances of the variable. There is a case in to check this is the case, and to warn you if you have not selected all instances:

case=2063


"odd effects", to a degree Extract Method expects / requires you to select something "intelligent" before triggering the command. It is possible to dream up some rather nasty edge cases that VA has no realistic hope of handling correctly, extracting a conditional return statement is one that comes to mind. I concluded we just need to spot this and warn the user, there was nothing else obvious to do.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000