2 Replies Latest reply: Oct 20, 2006 12:40 PM by 843853 RSS

    Syntax of new and null

    843853
      Remove "new" Operator

      Problem

      "new" is superfluous to the language.
      "new" refers at a fairly low level to memory management mechanics whereas it is preferable to use a more logic-based approach.

      Solution

      "new" is made optional syntax with the view of eventually removing it altogether.
      Integer i = Integer();
      Integer i = Integer(1);
      myCall(Integer(1));
      Benefits

      The language grammar is simplified.
      The language takes a step in the direction of abstracting away from low-level memory allocation/management mechanics and in favour of a logic-based approach.

      Drawbacks

      It may be considered that "new" provides clarity of description that a new object is being allocated.

      Clarity is not regarded as a problem. As long as it is possible to determine that a constructor is being invoked (which it is via the capitalisation of the method name) then it is considered that the programmer will easily become acustomed to the syntax.

      Compatibility

      The optional nature of "new" maintains backwards compatibility.


      Instance Constructors

      Problem

      Declaration syntax is overly verbose and cumbersome.

      Solution

      Constructors are embedded int the declaration.
      Integer i = new Integer(i);
      ...is replaced by:
      Integer i(1);
      Benefits

      Declaration syntax is simplified.

      Drawbacks

      It may be considered that "= new <Constructor>(..." provides clarity of description that a new object is being allocated.

      Clarity is not regarded as a problem. As long as it is possible to determine that a constructor is being invoked (which it is via the bracket organisation) then it is considered that the programmer will easily become acustomed to the syntax.

      Compatibility

      The optional nature of the new declaration structure maintains backwards compatibility.


      Better Memory Allocation and Management Syntax in Java

      This is a suggestion for a modification to the Java language. The report first identifies some (of what in my opinion are) problems in the Java language in the area of memory allocation/management then suggests some possible solutions.

      Problems

      * Syntax for "new" is cumbersome and not aesthetic:
      Integer i = new Integer();
           * "null" is not aesthetic syntax and is a left-over reminant of C/C++.
      if(i==null) ...
      * "null" and "new" refer to memory allocation at too low a level.
           
      * The fact that all objects may or may not be null is "untidy" and can lead to disorganised code:
      void myMethod(String s)
      {
           if(s!=null || s.size()==0) ...
      }
      * The null property of an object is used to specify that an object may or may not exist. It may be useful to explicitly specify that an object's existance is optional.

      Solutions

      Removal of the "new" Operator

      The "new" operator is completely removed and replaced with a much more compact syntax. Point-of-declaration constructors are introduced:
      Integer i;
      Integer i = new Integer();
      Integer i = new Integer(1);
      Integer i = null;
      is replaced by:
      Integer i;
      Integer i();
      Integer i(1);
      Integer i;
           Two advantages are gained, firstly the syntax is neater, more simple and more compact and secondly the syntax abstracts away from low level memory allocation mechanics in favour of a more logic-based approach.

      For consistency, point-of-declaration constructors are introduced for ordinal types:
      int i(1);
      Lazy Default Construction

      Newly created objects without constructors are created as "null" objects. At any point that an object is used it's state (null or not-null) is checked and if the state is null the default constructor is invoked.     
      Integer i; // i = null;
           
      i.call();  // if(i==null) i = new Integer(); i.call();
                     This method of construction allows an object to be declared but initialised at some future point, as is often useful. There is a further performance advantage that unused objects are never initialised. The current VM always performs null pointer checks on objects before using them so there is no performance loss from performing this check.

      Syntax is now much cleaner and memory management does not even appear to come into the equation:
      Integer i = new Integer();
      i.intValue();
           Compared with:     
           
      Integer i;
      i.intValue();
      Re-construction

      Objects may be reconstructed by invoking a particular constructor:
      Integer i;
      i = Integer(1);
      In this example, i is only constructed once due to lazy default construction.
                          
      Bypassing Lazy Default Construction

      If there is any particular need to ensure an object is constructed at the point of declaration then an explicit default constructor may be used:
      Integer i();
           Optional Objects

      The only use of null objects is to specify that an object is "optional". "null" is removed and replaced with an explicit "Optional Object" specification. The default construction of an optional object is null. There is no lazy default construction for optional objects:
      !Integer i; // i = null;
           An optional object's state (exists or does not exist) is determined     with a boolean-type expression:
      if(i) i.call();
      else ...
           Optional objects are useful for expressing optional parameters to a method:     
           
      Item find(Criteria c0, !Criteria c1)
      {
           ...
           Item i = getItem();
                
           // New syntax:
           if(c0.match(i) && (!c1 || c1.match(i))) return i;
                
           // Old syntax:
           if(c0.match(i) && (c1!=null || c1.match(i))) return i;
                
           ...
      }
           Optional paramters may be omitted instead of using "null":     
           
      Item i = find(c0,);
           Optional objects may be set to null using:
      i = !;
           For consistency, optional parameters may written as:
      Item i = find(c0,!);
      Conclusions

      "null" and "new" have been removed from the syntax altogether producing a more compact syntax which abstracts away from memory management mechanics.

      Lazy default construction neatly and efficiently takes care of deferred construction.

      Removal of "new" and "null" allows a guarentee that all standard objects are always valid thereby promoting cleaner code and removing the problem of forgetting to initialise objects.

      Optional Objects are introduced which allow for explicit specification of objects that may be null. This removes dependence on documentation to describe allowed object state and reduces possible confusion over object state.

      Optional method parameters may be omitted instead of using "null", and "null" detection is replaced with a boolean expression for compact and neat syntax that abstracts away from memory management mechanics.

      Finally, and importantly for future discussions, objects are now initialised with the same syntax as ordinal types:
      Integer i;
      int i;     
      Comments

      Comments and suggestions welcome.
        • 1. Re: Syntax of new and null
          843853
          As long as it
          is possible to determine that a constructor is being
          invoked (which it is via the capitalisation of the
          method name)
          You're changing the language in hidden ways, here. The language makes no distinction between upper and lower case characters.
          • 2. Re: Syntax of new and null
            843853
            As Java does not support objects on the stack, it makes sense to use C++ stack initialisation syntax for objects. To make it consistent with C++, allow both:

            Integer i(0);

            and

            Integer i = Integer(0);

            Can

            String value();

            be ambiguous in an interface?