Hiding class pointers -- was it a good idea?

eao197 eao197 at intervale.ru
Thu Aug 16 22:25:34 PDT 2007


On Thu, 16 Aug 2007 22:36:53 +0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> eao197 wrote:
>> I'm totaly agree with you. This is why I'm interested in D, not in C++.
>> But in the case with value type/reference type separation there are  
>> some benefits and drawbacks in the current D version. So I think that  
>> 'slicing' is not an important argument in defense of such separation.
>>  Because value/reference separation it is a fundamental feature of D so  
>> it is better to concentrate to minimization of value/reference/pointer  
>> conceptions. For example, what's about removing 'reference' at all?  
>> Lets D has only values and pointers:
>>  int i; // value.
>> int * pi; // pointer to value.
>> struct S { ... }
>> S s; // value.
>> S * ps; // pointer to value.
>> class C { ... }
>> C c; // Error! Value type cannot be used as value.
>> C * c; // OK. Pointer to reference type.
>>  void f( int i, S s, S * s, C * c ) { ... }
>
> But I think if one pulls on that string, one eventually winds up with  
> how C++ does it, with all of the problems.

(excuse me, but my poor English didn't allow me fully understand that. I  
could understand that you fear that such approach is too C++ish and it  
would lead to repeating typical C++ errors in D code)

I think such fear is a little strange for the language that already has  
pointer arithmetics and facilities like malloc/free/delete (and targeting  
to the same niches as C++).

But let to return to your goal: "Defining a problem out of existence is  
preferable, cheaper, and more reliable than depending on convention or  
more training." How about eluminating such problem as null pointers (I  
think it is much more common and dangerous problem than object slicing).

Some languages (Nice [1], Eiffel (in ECMA standard) [2], Spec# [3])  
targeted this problem by 'non-null' references (pointers). For example, in  
Nice there are two kinds of reference declarations:

class C {}
C non_null = ...; // Can't be null.
C? nullable = ...; // Can be null.

void f( C non_null_arg ) { ... } // non_null_arg can't be null.

non_null = nullable; // Error! Checked by compiler.
f( nullable ); // Error! Checked by compiler.
nullable = non_null; // Ok.
f( non_null ); // Ok.
if( null != nullable )
   f( nullable ); // Ok. In this branch nullable is not null.

I think if there was only one reference/pointer type in D than it would be  
easier to add such non-null references into the language. For example, it  
is possible to use another symbol for pointers:

class C {};
C # non_null = ...; // Can't be null.
C * nullable = ...; // Can be null.

void f( C # non_null_arg ) { ... } // non_null_arg can't be null.

non_null = nullable; // Error! Checked by compiler.
f( nullable ); // Error! Checked by compiler.
nullable = non_null; // Ok.
f( non_null ); // Ok.
if( nullable !is null )
   f( nullable ); // Ok. In this branch nullable is not null.

It would be much cleaner (imho) than something like:

C nullable_ref = ...; // Reference, can be null.
C# non_null_ref = ...; // Non-null reference.
C * nullable_ptr = ...; // Pointer, can be null.
C# * non_null_ptr = ...; // Non-null pointer.


[1] http://nice.sf.net
[2] http://se.ethz.ch/~meyer/publications/lncs/attached.pdf
[3] http://research.microsoft.com/specsharp/papers/krml136.pdf

-- 
Regards,
Yauheni Akhotnikau



More information about the Digitalmars-d mailing list