All right so we're not going to go back from the Boost implementation to our own implementation and
continue working with that because there are plenty of problems that we need to discuss.
And one of those problems is the problem of dependent properties.
Now Notice I'm using the word property.
Properties exist in C-sharp.
They don't exist in C++ as a concept but we suddenly can talk about age as a property or type person.
Now let me show you a complication which is very difficult to navigate in terms of this paradigm off
dependencies.
So let's suppose that we introduce a new property and I'm using the word property here.
So we're introducing a flag which indicates whether or not a person can vote.
So here I will say bhool get can vote Konst and I will return a greater than or equal to 16.
So let's suppose people can vote from age 16 onwards.
Now this presents a bit of a problem if you want to monitor the changes of this particular property
because there is no way to call notify on it because there is no Satar.
This is only a getter.
There is no set her and as a result it is entirely unclear where you should be calling notify.
Now of course as you may have guessed the right place to notify is set age because as you change the
age this probably gets affected as well.
So how would you actually go about doing this.
Well it's not going to be pretty unfortunately.
Let's actually rewrite that age to incorporate the idea of sending notifications on the changes in voting
status.
So first of all you would check for self assignment.
But before setting the age you with cash the old CAN VOTE value in order to subsequently see whether
it has in fact change or not so here you would say Aalto all can vote.
He calls gueth can vote like so you would set the name o the age rather and notify on the age.
And here you would compare the old value with a new value and that would determine whether you need
notification on can vote as well so if Hold can the vote is not equal to get can vote.
Then you send another notification so you notify on the subject and the name of the property or the
field in this case is can vote.
There is no actual field called can vote.
But since you have a Geter we can use this idea of this being a field notification.
So let's take a look at how all of this can work.
So coming back here we'll have a person P as before we're also going to have our Konsole person observer.
So we'll have Konsole person observe a CPO will connect we'll subscribe CPO to notifications on changes
in person and then we can mess about with person so we can set the age.
For example 15 and 16.
So Peter said age 15 and then duplicated to 60.
Now of course we need to modify if you'll change because we're only outputting values of the age.
So if field name is equal to can vote then let's see out how alpha source gets can vote.
There we go.
OK so having said all of this up let's actually execute this and see what's going on here.
All right.
So as you can see we have persons age changed to 15 persons age changed to 16 and then the can vote
status has actually changed to true.
So we're getting notifications on a dependent property but as you've probably guessed this approach
does not really scale.
I mean if you have a property dependent on two properties that's going to be really messy if you have
a dependent on probably be depended on probably see that's going to be just completely mental.
So what I'm trying to show here is the dependencies on notification so dependencies that on the different
kind of observables they become really tricky to handle especially when you don't have any set or you
just have a getter here and you want to notify on that getter.
So this is where you would typically build additional pieces of infrastructure to somehow facilitate
this traversal of dependencies and generating the appropriate notifications.