On my question about getters and setters in the video, I guess that these should be avoided; public data and object members should simply be declared public, despite what I've seen to be a common practice on many projects, and which seems to be promoted in many object oriented languages.
Ideally, there would be some way to overload the setting of an object or data "property" if the logic needs to be changed or limits imposed. I have created a Property template class in the past as Bjarne suggested, however, there is no elegant way for the parent class to overload the setter in the aggregated Property<T> member, and the syntax of accessing members of the property too often become property.get().member(), rather than property.member(), which is what you want to write.
From a language viewpoint, perhaps something like an overloaded "member access operator" would allow library writers to implement a setter or getter later if needed without changing user code. But without this, we suggest that if we need to change logic around setting or getting a member value, make the property private and recompile - we can easily find and update all the usages of the data member to use the new getter or setter.