You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I have a const reference to an object of this class I am not allowed to modify it. With a const ponder::UserObject, on the other hand, modifying this object is possible:
const MyClass myClassObject;
const MyClass& refToMyClassObject = myClassObject;
refToMyClassObject.Setter(41); // COMPILATION ERROR! Not allowed to modify a const objectconst ponder::UserObject myClassUserObject(refToMyClassObject);
myClassUserObject.set("Object", 42); // No compilation error, const object gets modifiedassert(refToMyClassObject.Getter() == 42);
With all that const around that behaviour may be counterintuitive.
From my point of view, what possibilities would exist to accomplish a consistent behaviour:
1. Do not allow to make a ponder::UserObject from a const object
Reasoning: WYSIWYG (= what you see [in the interface] is what you get). This would mean that in ponder e.g.
I guess this is not a very attractive option. If you like to reflect on a const object (e.g. to serialize it) and plan to only read its properties, you would have to apply a const_cast which is always something you like to avoid.
2. Allow a ponder::UserObject to be made from and to modify a const object consequently
Reasoning: Reflection is something that exceeds the normal possibilities of a language.
In this case, ponder's interface could essentially stay as it is now. To be consequent, though,
Of course, it would also have to be emphasized in the documentation that with ponder's reflection you are able to modify const objects.
3. Have a ponder::UserObject support a read-write as well as a read-only mode
Reasoning: Once againg WYSIWYG. With this option, if you make a ponder::UserObject from some const object this would then be the read-only mode where you would not be allowed to modify this object.
I guess this would be the best option, yet associated with the most effort.
What do you think? Was ponder intentionally designed for option 2? In any case, option 2 is what ponder now supports. Hence I would be happy if you would approve the modification I suggest in option 2 (which would avoid the const_casts that I now need to reflect on objects for which I have a const void*.)
The text was updated successfully, but these errors were encountered:
It's a tough one and perhaps needs a different angle. I did think about refactoring UserObject and making it policy based. I.e. you would pass it the traits that you would like it to have, like class member declarations can currently.
A UserObject currently owns a data holder, so two objects are allocated. This might be collapsed into one for some purposes. I never really got past that stage though.
In the case of const, as you mention, because of language constraints, perhaps opaque handles need to be used and a similar API to the runtime calling.
Consider a simple class with a getter and a setter
that is declared to ponder
If I have a const reference to an object of this class I am not allowed to modify it. With a
const ponder::UserObject
, on the other hand, modifying this object is possible:With all that
const
around that behaviour may be counterintuitive.From my point of view, what possibilities would exist to accomplish a consistent behaviour:
1. Do not allow to make a
ponder::UserObject
from a const objectReasoning: WYSIWYG (= what you see [in the interface] is what you get). This would mean that in ponder e.g.
would have to be changed to
I guess this is not a very attractive option. If you like to reflect on a const object (e.g. to serialize it) and plan to only read its properties, you would have to apply a
const_cast
which is always something you like to avoid.2. Allow a
ponder::UserObject
to be made from and to modify a const object consequentlyReasoning: Reflection is something that exceeds the normal possibilities of a language.
In this case, ponder's interface could essentially stay as it is now. To be consequent, though,
should in my opinion then be changed to
Of course, it would also have to be emphasized in the documentation that with ponder's reflection you are able to modify const objects.
3. Have a
ponder::UserObject
support a read-write as well as a read-only modeReasoning: Once againg WYSIWYG. With this option, if you make a
ponder::UserObject
from some const object this would then be the read-only mode where you would not be allowed to modify this object.I guess this would be the best option, yet associated with the most effort.
What do you think? Was ponder intentionally designed for option 2? In any case, option 2 is what ponder now supports. Hence I would be happy if you would approve the modification I suggest in option 2 (which would avoid the
const_cast
s that I now need to reflect on objects for which I have aconst void*
.)The text was updated successfully, but these errors were encountered: