Changes how model properties are checked to be set #28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I found a nuanced situation in how the
ModelPropertyclass determines whether a property is set or not. This ends up bumping into how PHP itself determines whether properties exist and are set on its own objects.Consider this unit test code:
We create a property that is nullable, then we explicitly set that value to null. So, is that property set or not?
Option 1: Follow PHP
isset()If we follow PHP
isset()rules, then no, it's not, because null is considered a special value in this case that means something is not set — it is a "nothing" value. Consider this:So to align with this means that null is considered a special "nothing" value indicating a property is not set.
Option 2: Follow strict assignment
This PR goes this route. In this case, we're functioning more like PHP's
property_exists()function. That is, until a value is explicitly set it is false, but once it is defined then it's true, regardless of whether it's false or not.Now, you'll notice in this PR I'm not using
property_exists(), and that's because it always returns true for a property defined as part of a class, even when that property has no initial value. For this reason, I'm using distinct internal flags for tracking whether the value has been set or not.Other considerations
If you look at the
ModelProperty::__construct(not modified in this PR), you'll notice a specialModelProperty::NO_INITIAL_VALUEis used. This was in light of this concept to differentiate between whether the property was given an initial value, versus it was given an initial value that is null.This also touches on the idea of dirty/clean values and committing/reverting said changes, as you'll see in the PR changes. The two concepts are connected but not quiet the same.