| Author |
 Topic  |
|
|
eddieparker
Senior Member
39 Posts |
 Posted - Nov 30 2018 : 8:41:27 PM
|
I'm using encapsulate field for the first time, and while I think I understand it now, it wasn't super obvious at first glance, and I thought I'd share the feedback.
Initially I couldn't tell what I was setting in the textbox (I have a large project, so it took forever to search all the references, so the label switching to help text didn't have anything to say at first). I'm assuming the first was the getter, and the second was a setter, but it wasn't obvious. I was expecting a dialog with two boxes for 'getter' and 'setter' specifically, and still am not sure why it's smashed into one text box.
Furthermore, it feels a bit limiting that I can't reuse the fieldname as the getter/setter. What I'd really like is if this field let me set the getter, the setter, and the new field name (which just defaults to the existing name). |
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Dec 02 2018 : 09:00:38 AM
|
First the name reuse point. What programming language are you working with? I have just double checked in VS2017, C++, and if you give the getter the same name as the variable, the code does not compile. So this restriction is not one that is coming from VA, VA is simply stopping you from generating invalid code.
The thinking behind the single edit box is that in C++ a lot of people have variable names like "m_Size", "_size" or even "m_nSize". Where VA recognises a prefix on the variable name the prefix is removed, and then the dialog is populated with the names for the getter and setter, that are the same, and can simply be accepted and used.
We are also trying to keep our refactoring dialog boxes fairly simple and quick to use, so you can be in and out of the dialogs without having to stop and do to much. As a result they are deliberately simple, but yes, this can unfortunately be a little confusing when you first encounter them.
Does the thinking behind this make a bit more sense now? |
zen is the art of being at one with the two'ness |
 |
|
|
pjwhams
Senior Member
25 Posts |
Posted - Dec 04 2018 : 08:54:03 AM
|
Also: Would be very useful to be able to *only* add a getter or setter (esp for immutable types where you don't want a setter)
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Dec 04 2018 : 10:11:42 AM
|
This is a good point, and we are considering doing this at some point:
case=95632
For now, when you are working with immutable types, you can delete the unwanted setter function afterwards. This is not ideal, but hopefully having VA find and update the direct calls to the member is still saving you quite a bit of time. |
zen is the art of being at one with the two'ness |
|
|
|
pjwhams
Senior Member
25 Posts |
Posted - Dec 04 2018 : 11:02:25 AM
|
| Thanks. My biggest timesaver would be the ability to select several member variables and automatically add get/set for them, though I can see that this would be difficult to know how the UI could work. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Dec 04 2018 : 11:13:13 AM
|
This is something we are considering doing, but as you say, its not really obvious how to do this with a sensible UI:
case=1091 |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
|
|
eddieparker
Senior Member
39 Posts |
Posted - Jul 12 2019 : 4:46:48 PM
|
| Thank you! |
|
|
| |
Topic |
|
Encapsulate Field: UI Improvements
