Nullable<bool> ?
-
Why exactly would TableRequestOptions.RequireEncryption Property[^] be Nullable - what does null mean? (Actually the Azure storage team like their Nullable<> - there's some nullable enums as well...)
-
Why exactly would TableRequestOptions.RequireEncryption Property[^] be Nullable - what does null mean? (Actually the Azure storage team like their Nullable<> - there's some nullable enums as well...)
:doh:
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
Why exactly would TableRequestOptions.RequireEncryption Property[^] be Nullable - what does null mean? (Actually the Azure storage team like their Nullable<> - there's some nullable enums as well...)
maybe!
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
Why exactly would TableRequestOptions.RequireEncryption Property[^] be Nullable - what does null mean? (Actually the Azure storage team like their Nullable<> - there's some nullable enums as well...)
null means it'll fall back to some default or setting, this is from the source:
modifiedOptions.RequireEncryption =
modifiedOptions.RequireEncryption
?? serviceClient.DefaultRequestOptions.RequireEncryption
?? BaseDefaultRequestOptions.RequireEncryption;TableRequestOptions.cs:135[^] Perhaps an enumeration would've made it clearer:
enum RequireEncryption
{
Default,
Yes,
No
} -
Why exactly would TableRequestOptions.RequireEncryption Property[^] be Nullable - what does null mean? (Actually the Azure storage team like their Nullable<> - there's some nullable enums as well...)
It means not set. It can trigger an auto-discover method, an error or a default behaviour.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
-
null means it'll fall back to some default or setting, this is from the source:
modifiedOptions.RequireEncryption =
modifiedOptions.RequireEncryption
?? serviceClient.DefaultRequestOptions.RequireEncryption
?? BaseDefaultRequestOptions.RequireEncryption;TableRequestOptions.cs:135[^] Perhaps an enumeration would've made it clearer:
enum RequireEncryption
{
Default,
Yes,
No
}But obviously the default for a bool (at the end of the day) will be false, if not stated otherwise...And if stated otherwise, than it should be part of the documentation...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Why exactly would TableRequestOptions.RequireEncryption Property[^] be Nullable - what does null mean? (Actually the Azure storage team like their Nullable<> - there's some nullable enums as well...)
Compare that with the CheckState property of a Checkbox: CheckBox.CheckState Property (System.Windows.Forms)[^].
nullcorresponds toCheckState.Indeterminate- the value has not been set. -
But obviously the default for a bool (at the end of the day) will be false, if not stated otherwise...And if stated otherwise, than it should be part of the documentation...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
It's not a boolean, it's a Nullable. Assigning a value to the property basically says "ignore all settings and defaults and do whatever I tell you to do", whether that's true or false. So leave it to null to allow some configuration option to determine whether to require encryption, or assign a value to make sure it either requires encryption or not. If it were a regular boolean, it would be impossible to determine whether the developer specified false or whether it's just the default value of a boolean. Nullable does allow for that. Personally I would've chosen an enumeration, as it's much more verbose, but a Nullable does the trick as well.
-
It's not a boolean, it's a Nullable. Assigning a value to the property basically says "ignore all settings and defaults and do whatever I tell you to do", whether that's true or false. So leave it to null to allow some configuration option to determine whether to require encryption, or assign a value to make sure it either requires encryption or not. If it were a regular boolean, it would be impossible to determine whether the developer specified false or whether it's just the default value of a boolean. Nullable does allow for that. Personally I would've chosen an enumeration, as it's much more verbose, but a Nullable does the trick as well.
+1 for the enumeration. It brings a lot more room for expansion and it isn't a PITA in serialization or marshalling.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
-
It's not a boolean, it's a Nullable. Assigning a value to the property basically says "ignore all settings and defaults and do whatever I tell you to do", whether that's true or false. So leave it to null to allow some configuration option to determine whether to require encryption, or assign a value to make sure it either requires encryption or not. If it were a regular boolean, it would be impossible to determine whether the developer specified false or whether it's just the default value of a boolean. Nullable does allow for that. Personally I would've chosen an enumeration, as it's much more verbose, but a Nullable does the trick as well.
It could be good explanation if it wasn't around bool...and if wasn't around this specific code... Did you see what the default value of the property (in BaseDefaultRequestOptions)? NULL... But actually in the code (line 158) it turns to false... Also the documentation states clearly that only true and false has meanings... Such nullable bool has meaning in cases where you want to force the developer to make a choice, but in this code is a clear case of wasting CPU cycles...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
It means not set. It can trigger an auto-discover method, an error or a default behaviour.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
Exactly...So the question remains...Why to use it in this code, where nothing happens and NULL interpreted as false...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Compare that with the CheckState property of a Checkbox: CheckBox.CheckState Property (System.Windows.Forms)[^].
nullcorresponds toCheckState.Indeterminate- the value has not been set.Which is there to aid cases of data bound control and required filed...but in the code above NULL simply interpreted as false and not as missing value...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
It could be good explanation if it wasn't around bool...and if wasn't around this specific code... Did you see what the default value of the property (in BaseDefaultRequestOptions)? NULL... But actually in the code (line 158) it turns to false... Also the documentation states clearly that only true and false has meanings... Such nullable bool has meaning in cases where you want to force the developer to make a choice, but in this code is a clear case of wasting CPU cycles...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
The method at line 158 is called ApplyDefaultsAndClearEncryption, which is internal as well. true and false do have meaning, as well as leaving it undefined a.k.a. leave it to some setting to determine whether the value will be true or false. I agree the code is unclear (as well as the documentation), but it does serve its purpose. How would you otherwise suggest to fall back to a default (which may either be true or false)?
-
The method at line 158 is called ApplyDefaultsAndClearEncryption, which is internal as well. true and false do have meaning, as well as leaving it undefined a.k.a. leave it to some setting to determine whether the value will be true or false. I agree the code is unclear (as well as the documentation), but it does serve its purpose. How would you otherwise suggest to fall back to a default (which may either be true or false)?
Maarten Kools wrote:
How would you otherwise suggest to fall back to a default (which may either be true or false)?
By deciding, what the default is! (it is decided to be false...) The problem of this code (and it of course doesn't mean that nullable bool to be banned at all) is that, at the end of the road there is nothing about null value...It not used in any way to define a different behavior, but simply changed to false behavior...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Maarten Kools wrote:
How would you otherwise suggest to fall back to a default (which may either be true or false)?
By deciding, what the default is! (it is decided to be false...) The problem of this code (and it of course doesn't mean that nullable bool to be banned at all) is that, at the end of the road there is nothing about null value...It not used in any way to define a different behavior, but simply changed to false behavior...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
For now. It is extendable / patchable for future developements, which means that in version x+1.0 default may become true or there will be a mechanism to decide independently. It leaves a door opened to change - that's why I and other programmers would have used a enum, still having it nullable prevents errors, even when interfacing with different data sources. Only the things that REALLY must exist or any reasoning is pointless should be non-nullable... unless you're developing a system which must be extremely picky about its inputs.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
-
For now. It is extendable / patchable for future developements, which means that in version x+1.0 default may become true or there will be a mechanism to decide independently. It leaves a door opened to change - that's why I and other programmers would have used a enum, still having it nullable prevents errors, even when interfacing with different data sources. Only the things that REALLY must exist or any reasoning is pointless should be non-nullable... unless you're developing a system which must be extremely picky about its inputs.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
Of course it is impossible to future version to change default value (or behavior) - that will break applications in an instance...You not even ca nto introduce a new meaning for null, as it is today interpreted as false and changing that will also break applications... If you are aiming to future options, you have to use enum, and add new values for new features...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
It's not a boolean, it's a Nullable. Assigning a value to the property basically says "ignore all settings and defaults and do whatever I tell you to do", whether that's true or false. So leave it to null to allow some configuration option to determine whether to require encryption, or assign a value to make sure it either requires encryption or not. If it were a regular boolean, it would be impossible to determine whether the developer specified false or whether it's just the default value of a boolean. Nullable does allow for that. Personally I would've chosen an enumeration, as it's much more verbose, but a Nullable does the trick as well.
That's fine, if you bother to document what the null actually means. Without that, its a bug waiting to happen.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
But obviously the default for a bool (at the end of the day) will be false, if not stated otherwise...And if stated otherwise, than it should be part of the documentation...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
obviously the default for a bool (at the end of the day) will be false, if not stated otherwise...And if stated otherwise, than it should be part of the
IMO, this is the most significant statement in this thread. The thing that drew me into this thread was its subject, which made me wonder how a bool could be considered nullable. When I see the word "nullable," I assume that the context is an object, rather than a primitive type such as bool, int, long, uint, ulong, double, etc.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
