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