questions on nullability

Peter Hall peterjoel at gmail.com
Thu Jun 15 04:17:52 PDT 2006


>
> (redacted) writes:
> > lth at opera.com writes:
> > > The entire reason that the class definition can be annotated is to
> > > make it easier for the programmer not to have to worry about null when
> > > using classes for which a null value does not make sense.  The
> > > canonical example is "Complex": this is usually viewed as a "value
> > > type", ie, it does not normally make sense to have Complex values that
> > > can be null.
> >
> > Isn't there then an argument for adding a syntax to provide a default
> value
> > in place of null, much as int or Number are defaulted to 0?
>
> That would not prevent you from later assigning null to a variable of
> that type, though, or pass null to a function taking that type.



It would if null was automatically converted to this default value, as
happens with int.


The intent of the non-nullability proposal is to be able to add
> annotations to the program that guarantee that that sort of thing will
> not happen, and that null-pointer exceptions won't be thrown.  It goes
> beyond creating sensible non-null default values.



Yes, I wasn't suggesting  default values as a direct replacement to
non-nullable annotations. But, I think default values is much better
solution to the specific Complex example. In fact, I think default values
would tackle most of the reasons why you'd want to annotate a class
declaration as non-nullable.

However, you introduce other problems when performing explicit coercions
between types and the non-nullable version. In these situations, if you end
up pushing the resolution to run-time, yielding coercion errors (and
possibly null-pointer exceptions if "as" operator is used) non-nullability
hasn't really achieved it's objective..


There has been rather a lot of discussion about whether default values
> could be provided for non-nullable variables; the discussion page for
> the proposal records some.  In practice default values are fraught
> with issues, not the least because you'll want default values to have
> "value semantics": to be either read-only or copy-on-write.


Ok. I missed that. I'll check out the discussion pages.


--lars
>
> (CC'ing the discussion list even though I received the reply
> privately; it's of general interest.  Sender's name redacted.)



oops.  most of the lists I subscribe to have reply-to as the list itself.


> Just a stab at
> > the syntax here but, to use your Complex example:
> >
> > public class Complex extends Object = new Complex (0,0) {
> >      //
> > }
> >
> >
> > public class Complex
> >     extends Object
> >     default new Complex(0,0)
> > {
> >      //
> > }
> >
> > This would be far more useful than simply banning null. I would expect
> the
> > statement defining the default value could be made up from any static
> > methods or compile-time constants.
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20060615/ceaa8c66/attachment.html 


More information about the Es4-discuss mailing list