[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: [ProgSoc] Programming! Code!



Whoops... sent to Raz only.

Nigel

> -----Original Message-----
> From: Nigel Sheridan-Smith [mailto:nbsherid@xxxxxxxxxxxxx]
> Sent: Saturday, 21 October 2006 9:14 AM
> To: 'Roland Turner'
> Subject: RE: [ProgSoc] Programming! Code!
> 
> 
> 
> > -----Original Message-----
> > From: owner-progsoc@xxxxxxxxxxxxxxxxxx [mailto:owner-
> > progsoc@xxxxxxxxxxxxxxxxxx] On Behalf Of Roland Turner
> > Sent: Friday, 20 October 2006 2:40 AM
> > To: ProgSoc List
> > Subject: RE: [ProgSoc] Programming! Code!
> >
> > On Thu, 2006-10-19 at 21:03 +1000, Nigel Sheridan-Smith wrote:
> >
> > > > Interesting; spec# claims to add non-null types, but your test
> > suggests
> > > > that even System.Boolean is already non-null.
> > > >
> > > > Oh well, syntax trivia...
> > > >
> > >
> > > Maybe by "non-null" they mean objects that can never be null (in valid
> > > code). Constants without being constant?
> >
> > Your test suggests that Boolean already cannot be null in C#. I'm not
> > sure what you mean by "constants without being constant".
> >
> 
> Ahh sorry.
> 
> * Value types such as bool / System.Boolean can have values "true" and
> "false"
> 
> * Reference types can be "null" or a reference to a object stored on the
> heap, etc
> 
> * Nullable value types (.NET 2.0) have the additional possible value
> "null". So bool? / System.Boolean? allows "null", "true" and "false"
> 
> * Non-nullable reference types (Spec#) are references that can never be
> null. The language enforces the constraint (or creates an invariant) that
> the object can never be nulled. Obviously, it will be effectively "null"
> when it is destroyed, but your source code can never express this.
> 
> So normally in most OO languages:
> 
> Object x = null;
> Object y = new String();
> x = y;
> y = null;
> 
> But with a non-null type:
> 
> Object y = new String()
> Object x = y;
> 
> ... is all that is valid. The objects are obviously destroyed when they go
> out of scope and there are no outstanding references to them.
> 
> I was making an analogy to C/C++ "const", or Java's "final". The value
> must be initialised when the variable is defined. However, in the case of
> a non-nullable type you can still change the value after it is defined, as
> long as you never set the value to null. Hence, "constant without being a
> constant". Some runtime checking would probably be required to ensure
> dynamic types conversions, value assignments, etc are all valid.
> 
> Well, that's what I assume anyway. I can't find any public documentation
> in a hurry to support that this is what they actually mean.
> 
> Cheers,
> 
> Nigel


-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.