Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Encapsulate Field: UI Improvements

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

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

Forum code is on.
Html is off.

Check to subscribe to this topic.

T O P I C    R E V I E W
eddieparker 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).
7   L A T E S T    R E P L I E S    (Newest First)
eddieparker Posted - Jul 12 2019 : 4:46:48 PM
Thank you!
sean Posted - Jul 12 2019 : 3:13:26 PM
case=95632 is implemented in build 2341
feline 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:

pjwhams 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 Posted - Dec 04 2018 : 10:11:42 AM
This is a good point, and we are considering doing this at some point:


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.
pjwhams 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 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?

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