Could private values like UI width be protected in a public var like value?

Hi,
Could private values that we like to edit and save through getters and setters be in a public variable class rather than being private. Direct access to the actual float could still be private to the class through a friend connection. Then we could access the values with class getter and setter or directly, but still with encapsulation. This would make it very easy to link layouts to ValueTrees, to add lambda for listeners etc.

I’m not sure if I understood that right, juce::var is one scalar variable, that can have different types (by aggregation rather than polymorphism).

But this value can be a DynamicObject, is this what you are talking about? In which case you simply use the getters and setters of the DynamicObject and you are good to go.

Note that both, var and DynamicObject are not designed to be inherited, so protected would be meaningless in this case.

Hope that explains it a bit

I was more pondering an alternate form of encapsulation using a public friend class to wrap the private variable, share it privately with the friend class and yet allow it to code as if it were public elsewhere where it still follows encapsulation principles. I chose var because it already exists.
I have been reworking my plugin so that everything loads dynamically from an editable xml document. The current encapsulation locks me out of many otherwise simple, yet on mass solutions. Just to save a plugin window size is a great example.

No worries, helps me sometimes to get a fresh perspective…

In terms of ValueTree, there is a handy method, ValueTree::getPropertyAsValue(). This Value can be used to connect to UI elements, e.g. by getting a Slider’s value object and calling referTo (otherValue) on that, so they will be linked/updated. No polymorphism needed here.

For your plugin window size, I think it is best to simply update/apply that in your ValueTree in getStateInformation/setStateInformation, since that is the only place where this can be changed apart from being dragged.

Hope that helps

Thanks for that info

My written communication is not good. Here is the most basic example of what I mean so nothing is lost. Is it a good idea creating “pseudo” public variables for easy passing around? This makes it far easier to save whole instances of classes to ValueTrees, attach lambdas and the list goes on.
I assume this is what friends are for

    class PrivateFloatVariable
    {
    public:
        friend class Window;
       PrivateFloatVariable(float setFloatWith) { privateFloatVariable = setFloatWith; }
        float get() { return privateFloatVariable; }
        void reset(float setFloatWith) { privateFloatVariable = setFloatWith; }
    private:
        float privateFloatVariable;
    };
    
    class Window
    {
    public:
        PrivateFloatVariable width;
    private:
    };

To access the private width in the window class, one can now use width.privateFloatVariable.
We now have an encapsulated “pseudo” public variable we can pass around, with standardized methods.
Thank you for your thoughts.

We already have a class to do that kind of thing with Values:

https://docs.juce.com/develop/classCachedValue.html

Hi Anyone(I do not wish to waste Jule’s time),
A number of times I have been way off the mark and I may be. I have a lot to learn. Thank you for your time up front.
I was proposing a standardized getter and setter. The current getters and setters are great, but I would love an encapsulated variable to pass around.
As illustrated in the following example changes, excluding the fact that CachedValue has access to dereference operators and does not template a Rectangle:

    template <typename Type>
class CachedValue   : private ValueTree::Listener
{
public:
    friend class Component;
………
……….
}

class JUCE_API  Component  : public MouseListener
{
public:
    CachedValue<Rectangle<int>> boundsRelativeToParent;
………
……….
int getX() const noexcept { return  boundsRelativeToParent.cachedValue.getX(); }
………
……….
private:
………
……….
//    Rectangle<int> boundsRelativeToParent.cachedValue;
………
……….
}

Thank you