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

Re: [ProgSoc] Programming! Code!



On Fri, 2006-10-20 at 03:25 +1000, John Elliot wrote:

>  3. In a boxed class
> 
> In this case the CLR provides an automatic facility for allocating a 
> value type in a 'stub' class on the heap. I imagine you understand how 
> boxing works. But basically it's like this:
> 
>  struct S {
>    public readonly Int32 V;
>    public S( Int32 v ) { V = v; }
>  }
> 
>  class C {
>    public readonly S S;
>    public C( S s ) { S = s; }
>  }
> 
>  S s = new S( 123 ); // allocates an unboxed value on the stack
>  C c = new C( s );   // equivalent of 'boxing' a value, now allocated
>                      // as a readonly member of c on the managed heap
>  S v = c.S;          // equivalent of 'unboxing'. copies the value
>                      // from the heap into the value v on the stack

OK, got it. Not yet comfortable with it.

> > > Ahhh more reading...
> > >
> > > .NET 2.0 adds Nullable types, so you can explicitly add "null" as a
> > > valid value to the value types. Presumably this is used for RDBMS.
> >
> > If I'm getting this right (I'm still finding it difficult to
> > believe), then C# is the first widely-used OO language that I've
> > encountered which does not have null object references (explicit
> > references to no object). This is not quite the same as "null" (the
> > complete absence of a value, rather than an explicit reference to no
> > value) in a relation, but the two can be and frequently are readily
> > mapped onto each other.
> 
> Value types have never been able to contain a null value in any CLR 
> language, including VB7 and C# 1.0.

Having finally grasped the non-Object nature of Boolean, this is now
clear.

> The problem with mapping 'null' to 'NULL' is in the decision about 
> whether to implement TVL or not. assert( null == null )?

I have no problem with expressions being evaluated in the relevant
contexts (null == null, but NULL IS NULL and also !(NULL == NULL) and
also !(NULL != NULL)). Granted, this is non-optimal, but Java doesn't
work on relations at present, and altering SQL to suit Java et al is
non-starter. There are several other expressions that evaluate
differently when Java is used to access an RDBMS, depending upon whether
the context is Java or SQL, null/NULL just happens to be the most
confusing example.

> > The other place that it's frequently useful in Java is to explicitly
> > represent intentional absence of a value, e.g. for a "don't know" or
> > "not specified" situation; a Boolean object reference can, by virtue
> > of being an object reference, be a null object reference (a explicit
> > reference to no object) and, therefore, explicitly represent the
> > absence of a value. "boolean" on the other hand is a primitive value
> > type (not a reference) and, therefore, cannot be "null" in either
> > sense.
> 
> You statements regarding what can and can not be done here are 
> incorrect.

Erm, you wanna rethink that? I've worked with this language extensively
since a few weeks after its alpha release back in 1995. I am convinced
that what I have written is correct, even in the presence of j2se5's
autoboxing.

- Raz


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