| Author |
 Topic  |
|
|
KoenTanghe
Senior Member
Belgium
28 Posts |
 Posted - Jun 28 2007 : 12:07:02 PM
|
Hi,
first: I love VAX! Keep up the good work!
Now, to my question: would it be possible to add another "Encapsulate Field" that works on simple types (user can select it himself if he knows it's a simple type, no need for VA to detected that)? Why I mean is this:
class C
{
int m_ID;
}
now yields:
const int& GetID() const { return m_ID; }
void SetID(const int& inID) { m_ID = inID; }
while I would prefer this, since it's a simple type:
int GetID() const { return m_ID; }
void SetID(int inID) { m_ID = inID; }
I tried editing the AutoText entries, by adding a new entry with the Title "Refactor Encapsulate Simple Field" and with this code:
$end$$SymbolType$ Get$GeneratedPropertyName$() const { return $SymbolName$; }
void Set$GeneratedPropertyName$($SymbolType$ in$GeneratedPropertyName$) { $SymbolName$ = in$GeneratedPropertyName$; }
but that didn't seem to work (no second Refactor item with the given title pops up)... |
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jun 28 2007 : 12:49:40 PM
|
Which IDE and version of VA are you using?
VA already does this for me, using the default Encapsulate Field autotext entry in VS2005 with VA 1557. |
zen is the art of being at one with the two'ness |
 |
|
|
KoenTanghe
Senior Member
Belgium
28 Posts |
Posted - Jun 29 2007 : 08:10:58 AM
|
I'm was using VAX 10.3.1549.0 in VS2005, but I now installed the latest (1557), and it's still the same.
I then also deleted the entry I had to restore the default setting, and saw this:
in the default, the "Encapsulate field" will not use references on the function arguments and return types, which is what I want for simple types.
However, for class types, I do want references on function arguments and return types (I probably edited the default into using references myself some time ago, whereas that is not always what I want). And it doesn't seem possible to have both at the moment.
So, to summarize:
int m_ID;
-->
int GetID() const;
void SetID(int inID);
but (where Shape is a class, we want references)
Shape m_Shape;
-->
const Shape& GetShape() const;
void SetShape(const Shape& inShape);
[it's not about the Get/Set, but about the references/no references]
If it would be possible to add a second "Encapsulate Field", so that there is one without references, and one with references, that should be sufficient. If VAX can detect if it's a simple data type (int,float,double,bool,...) and make the choice all by itself, that's be fantastic of course.
I hope this made things a bit clearer? Thanks for listening! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jun 29 2007 : 12:21:51 PM
|
I follow now. Having a second autotext entry is not ideal, and anything that forces the user to choose which rule to use every time they trigger Encapsulate Field is going to get very irritating very fast 
So I have put in a feature request for VA to do this automatically:
case=7382
For now your current edit to the autotext rule is the best solution, since this way you get references for all object types, and it is probably quicker to delete the reference when you don't want it than it is to add it. |
zen is the art of being at one with the two'ness |
|
|
|
sl@sh
Tomato Guru
Switzerland
204 Posts |
Posted - Jul 02 2007 : 04:22:52 AM
|
Just to add a possible corner case: I've seen a lot of projects where typedefs are being used for the possible case of future changes to the basic data types used internally. E. g. a 'typedef float Scalar' that might be changed to 'typedef double Scalar' when higher precision becomes a higher priority than saving memory, or 'typedef short ShapeID' that might be changed to 'typedef long ShapeID' when the number of IDs grow beyond what was originally anticpated.
As a result, 'simple' types might be hidden in typedef'ed names. This is definitely something VA would need to check before deciding what kind of type it is looking at. The bad thing about these typedefs is that a typedef that is currently a simple type might actually be changed to a class type later - for instance in a ultra high precision math module the 'typedef double Scalar' might be changed to 'typedef class CVeryLongDouble Scalar' eventually. Not that I think this will cause too many problems, just a case to consider... |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jul 02 2007 : 07:15:27 AM
|
ouch. When I put in the case I was thinking that the definition of a "simple" type was "built in simple type", so effectively a hard coded list of simple types. However I did not make that thought clear.
I have added a note to the case about this. Thank you for the thought |
zen is the art of being at one with the two'ness |
|
|
|
KoenTanghe
Senior Member
Belgium
28 Posts |
Posted - Jul 02 2007 : 07:41:18 AM
|
@ sl@sh:
Yes, that would indeed be even better than the simple builtin types only.
@ feline:
Thanks for considering the suggestion! |
|
|
| |
Topic |
|
Refactoring: Encapsulate Field for simple types
