JADE Environment Development Ideas

What's new in the upcoming JADE release?


The JADE 2022 release meets tomorrow’s business demands.

Start your update to JADE's latest release

nullable types

Let's be able to tell the difference between 0 and null, for example.

Has something been set to 0 or has it not been set? I don't know!

  • Ty Baen-Price
  • Jun 24 2020
  • Future consideration
  • Attach files
  • Ty Baen-Price commented
    29 Jun, 2020 04:40am

    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.

  • Guest commented
    29 Jun, 2020 04:22am

    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 :)

  • John Beaufoy commented
    29 Jun, 2020 12:48am

    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?

  • Ty Baen-Price commented
    28 Jun, 2020 11:14pm

    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....

  • Guest commented
    28 Jun, 2020 10:24pm

    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.

  • Ty Baen-Price commented
    26 Jun, 2020 02:29am

    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"

  • Kevin Saul commented
    26 Jun, 2020 02:14am

    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.

  • Ty Baen-Price commented
    25 Jun, 2020 08:34pm

    Before a JEDI is voted on, I only consider things that would make it impossible. What are you thinking?

  • John Beaufoy commented
    25 Jun, 2020 10:51am

    Like the concept Ty.

    Wondering what you're thinking in terms of how it would be implemented?

  • Kevin Saul commented
    24 Jun, 2020 11:21pm

    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.