Open Weeena opened 7 years ago
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*
.)