--- Comment #4 from Christopher the Magnificent <> 
2011-05-13 15:29:16 PDT ---
Okay, thanks for bringing me up to speed with the existing "const(Object) ref"

Here's my thought.  The const(Object) ref syntax, while getting the job done,
is undesirable because it highjacks an existing syntax in such a way that
previous meaning of what is being added to is lost.

Here's what I mean.

        const(MyObject)   myVar;

In the above thing, "const(Object)" is the type, and it means a constant
variable referencing a constant object of class MyObject.

Now we have

        const(MyObject) ref    myVar2;

Is myVar2 a reference to an entity of type "const(MyObject)"?  In other words,
is myVar a *reference to a constant variable referencing to a constant object
of class MyObject*?

Nope!  But I submit that that's exactly what this syntax suggests to a person
of average intuition.

This "ref" syntax implies two levels of pointers as in "a ref to a const ref to
a const object".  This is not what the syntax actually does.  When you have the
ref after it then the "const(MyObject)" part suddenly stops meaning "constant
variable referencing constant object" and starts meaning "constant object".
Therefore, the syntax is to me misleading and liable to be misunderstood.  

Second, in the mailing list I read someone wanting to do this:

        MyObject ref    myVar;  // ref keyword ensures that MyObject is a
class; error if MyObject is a struct

This seems to encourage people to indiscriminately insert keyword "ref" and
litter their D code with syntactic fluff that, while providing a sanity check,
doesn't actually change the meaning of correctly written code, making stuff
harder to read, and all this rather than requiring people to just look up the
interface and double check that something is indeed a class before they start
to use it.

There may be a benefit to instituting a compiler check that asserts something
is a struct vs. a class, but I don't think using the keyword ref is the best
way to do this.  I have my own idea about this--just permit the optional
prefixing of the type names with "class", "struct", or "enum" and the compiler
doubles checks it.  This is a better solution because those three keywords
reinforce what they're doing, rather than restating the obvious (that the
variable is storing a reference).

Now look at my syntax:

        // the following two are equivalent
        objconst MyObject   myVar;

        const(objimmutable(MyObject))*  myPtr;  // pointer to const variable
referencing immutable object

        objconst(MyObject)[]  myArray;   // array of mutable variables
referencing const objects

* This syntax is visually cleaner
    * Parentheses may be omitted for the simple case above--not so with
<const(MyObject) ref>
    * Requires only one keyword instead of two.
* It doesn't appear to change the meaning of existing syntax like
<const(MyObject) ref> does
* When the syntax is used, it always has an effect upon the meaning of the
program.  Does not turn into fluff.
* It is more specific in its usage and it its effect than the alternative.
* It solves a single problem well, rather than trying to do several things at
once in an obscure fashion.

I think I like the variety of keywords without the underscores best.  Do you
like my keywords better with or without underscores?

(In reply to comment #3)
> (In reply to comment #2)
> > Where do I find the "const(Object) ref" syntax described?  I've never run
> > across it in the D Language Reference.  Point me to some info about this
> > particular syntax and then I'll be able to comment on how my own syntax may 
> > be
> > superior.
> > 
> This is a third-party proposal, and isn't even approved. You won't find it in
> the official reference ;)
> See bug 5325 and the huge thread in
> You may also search for "tail const" to find a lot of previous discussions.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to