[C++-sig] Retiring "ref", etc.

[joel de guzman]

----- Original Message ----- 
From: "David Abrahams" :

> > I'm inclined to suggest having just an ^object^ that covers the
> > special error case if the only difference between an ^object^
> > and a ^reference^ (or ptr), is the signalling of the error condition.
> 
> I'm against this approach. The current reference<> throws by default if you
> pass null to the constructor, and that default behavior is used in 99% of
> cases. It works with Python synergistically: when Python returns via an
> error it becomes an exception in the user's code.
> 
> That really is the behavior users want from their object type in most
> cases. Also, it's a basic principle of reliable software engineering that
> "invalid" object states are best avoided. It's much cleaner to know that if
> I get passed an "object", it's valid, and not some "error state". Otherwise
> code is either full of checks to see whether we're holding the error
> object, or (more likely) it simply ignores errors because they're too much
> trouble.

I see. I too am against propagating error conditions. Perhaps I had
the mistaken notion that such states are part of life, which is not
unusual in a dynamically typed environment. As it is, code using
dynamically typed data is abundant with checks. Checks that we
take for granted in statically typed C++, for example. 

Yes. I agree that if it used in less than 1% of the cases, then it's 
better to deal with it differently.

> What I'm heading toward is a two-level interface: a smart pointer type
> ("reference<>", or pick a better name) which can be null, for low-level
> interfacing with Python, and a higher-level type, "object", which can never
> be null, and which provides a nice Python-objec-like interface.

Hmmm, so it seems that we have two types which are strikingly
similar to what we have in C++. 1) an object-reference that
cannot be null and 2) an object-pointer that can be null. While
object is indeed a nice name, the presence of another lower
level class that can point to a null object seems to suggest
(at least to me) the ref and ptr prefix. obj_ref and obj_ptr
comes to mind. Or, if you want to keep the nice "object" as
a name, just name the other "object_ptr". After all, this is a lower
level class that the client should avoid using if possible, so the 
longer name is ok.

    object: cannot be null [high level interface]
    object_ptr: can be null [low level interface]

Cheers,
--Joel