Primatives in JADE are not nullable. It is possible to set them to null, but not possible to distinguish a value of null from 0 (or whatever their default is). If a thing is nullable, the value of null gives the thing the extra state that you were talking about, John.
My migration comment was in regards to finding source code with null, reversePos to find the property/parameter/attribute. If found with applicable type then set it accordingly in code.
Primitive types are nullable already, its just that Jade treats null prims different to null objects when used as a receiver. What would the benefit be for “true” nullable prims? I only see downside, in that we would carry two meanings for null and to be consistent arguably prims should crash in the same way a null object does.
My interest is with knowing if a field has been set/initialised to a value already by code, not so much that it is null. The simplest way to achieve this could be by way of a new primitive function we could call to check the state? Might prove difficult for prims already in the db, but worth some thought?
There is no issue with the physical migration of 0s or ""s or whathaveyous into null. The issues are a) is it appropriate to do that? I.e. JADE doesn't know if your empty string means null or empty string, only YOU know that, and b) every existing application has been programmed around the assuption that 0 = null and "" = null. If we change things so that 0 <> null and "" <> null, we would break a lot of things....
I like the idea, I tend to specify null-based typed values to avoid honest mistakes currently. e.g. textBox.text := ""; whereas in the past I could of walked away with textBox := null and had puzzling null errors. Other dinosaur languages I've used look at me confused if I try to set a primitive value to null.
My colleagues probably would disagree with me, is this a case where you suck it up and don't have backward compatibility? Can Jade have a well-tested migration to convert primitive type null's to their type equivalent. I'd assume an type of Any of null is fine.
Yeah I thought you might mean backwards compatability. We always think of that. The two standard options are either to introduce new types ie. NullableInteger, or to make nullable a property of primatives which is user configurable but defaults to off ("the old behaviour").
We would never consider making existing primatives nullable in situ. Rule 1 is "don't change the results of their calculations without telling them"
Couple of areas come to mind which would make this difficult to implement:
We've existing code which compares variables to null already, rather than 0, false or an empty string literal.
Dates & times which default to the current date/time are an existing bugbear, these types should always be defaulted to null, which would complement this proposal, but again, we've got existing code which may break if they stopped defaulting as they currently do.
What we really need is a way of targeting which version of the compiler should be used, ideally something which could be set at the schema & class level. This'd then allow for new/breaking changes like this to be introduced, without losing backwards compatibility for existing code and enabling us to upgrade our code for latest version of compiler as it's maintained rather than a large-scale headache as part of each JADE upgrade.
Would this apply to booleans as well? It'd be good if this did & could solve problems we've encountered previously with web services, where it's unclear if calls from .NET have set a boolean value to false explicitly or it was just left as null.
Ty Baen-Price
Primatives in JADE are not nullable. It is possible to set them to null, but not possible to distinguish a value of null from 0 (or whatever their default is). If a thing is nullable, the value of null gives the thing the extra state that you were talking about, John.
Attachments Open full size
My migration comment was in regards to finding source code with null, reversePos to find the property/parameter/attribute. If found with applicable type then set it accordingly in code.
I know it is a big task and probably not effective, the reason I brought it up is that I can't see how making it backwards compatible will make the change effective. People can do the same old anyway or as what John said in regards to nullable primitives. The only thing I can of is to make Jade comply with a "strong type" behaviour: https://secure.jadeworld.com/JADETech/JADE2018/OnlineDocumentation/content/resources/userguide/ch1conceptsterms/jade_language.htm
Most importantly I was definitely correct that my colleagues would disagree with me :)
Attachments Open full size
Primitive types are nullable already, its just that Jade treats null prims different to null objects when used as a receiver. What would the benefit be for “true” nullable prims? I only see downside, in that we would carry two meanings for null and to be consistent arguably prims should crash in the same way a null object does.
My interest is with knowing if a field has been set/initialised to a value already by code, not so much that it is null. The simplest way to achieve this could be by way of a new primitive function we could call to check the state? Might prove difficult for prims already in the db, but worth some thought?
Attachments Open full size
There is no issue with the physical migration of 0s or ""s or whathaveyous into null. The issues are a) is it appropriate to do that? I.e. JADE doesn't know if your empty string means null or empty string, only YOU know that, and b) every existing application has been programmed around the assuption that 0 = null and "" = null. If we change things so that 0 <> null and "" <> null, we would break a lot of things....
Attachments Open full size
I like the idea, I tend to specify null-based typed values to avoid honest mistakes currently. e.g. textBox.text := ""; whereas in the past I could of walked away with textBox := null and had puzzling null errors. Other dinosaur languages I've used look at me confused if I try to set a primitive value to null.
My colleagues probably would disagree with me, is this a case where you suck it up and don't have backward compatibility? Can Jade have a well-tested migration to convert primitive type null's to their type equivalent. I'd assume an type of Any of null is fine.
Attachments Open full size
Yeah I thought you might mean backwards compatability. We always think of that. The two standard options are either to introduce new types ie. NullableInteger, or to make nullable a property of primatives which is user configurable but defaults to off ("the old behaviour").
We would never consider making existing primatives nullable in situ. Rule 1 is "don't change the results of their calculations without telling them"
Attachments Open full size
Couple of areas come to mind which would make this difficult to implement:
We've existing code which compares variables to null already, rather than 0, false or an empty string literal.
Dates & times which default to the current date/time are an existing bugbear, these types should always be defaulted to null, which would complement this proposal, but again, we've got existing code which may break if they stopped defaulting as they currently do.
What we really need is a way of targeting which version of the compiler should be used, ideally something which could be set at the schema & class level. This'd then allow for new/breaking changes like this to be introduced, without losing backwards compatibility for existing code and enabling us to upgrade our code for latest version of compiler as it's maintained rather than a large-scale headache as part of each JADE upgrade.
Attachments Open full size
Before a JEDI is voted on, I only consider things that would make it impossible. What are you thinking?
Attachments Open full size
Like the concept Ty.
Wondering what you're thinking in terms of how it would be implemented?
Attachments Open full size
Would this apply to booleans as well?
It'd be good if this did & could solve problems we've encountered previously with web services, where it's unclear if calls from .NET have set a boolean value to false explicitly or it was just left as null.
Attachments Open full size