Mr. Fortin, thank you for your thorough response. I have just a few
comments.
On 5/17/11 9:07 PM, Michel Fortin wrote:
On 2011-05-17 20:00:55 -0400, Christopher the Magnificent
<ultimatemacfana...@gmail.com> said:
Now I understand that another syntax has been nominated to do this job
which is the const(Object)ref syntax.
I don't think there has been any official word on that. But many people
have shown support for it.
I dislike that syntax because "const(Object)" means a constant
variable referencing a constant data structure, and "const(Object)ref"
LOOKS like it should be a reference to a variable of type
"const(Object)" -- to me it suggests a variable referencing a constant
variable referencing a constant data structure. "const(Object)ref"
suggests TWO levels of pointers, but that is not the meaning being
ascribed thereunto.
But ask yourself this: why does "Object ref" looks like a double
reference to you? I'll guess an answer: because of previous knowledge of
the language that says to you that "Object" is always implicitly a
reference type.
I think that previous knowledge of the language ought to inform the
direction of future additions. My previous knowledge of D says that, as
in Java, a variable of type Object (where Object is a class-based type)
is a reference type.
The basic idea behind the const(Object)ref proposal is to change the
meaning of "Object" to become a shortcut for "Object ref".
I disagree that this is something that should be changed.
In other
word, the "ref" part is always there, and if you omit it, it's added
implicitly for you.
I am personally opposed to giving "Object" and "Object ref" the exact
same meaning. This strikes me as confusing because we have been
conditioned to understand that "Object" means reference to data
structure for an object, but in the second instance "Object" refers to
the data structure itself. Inconsistent and confusing, say I.
Try to look at thing from a this new perspective and
it'll fit better.
I picked the keywords "objconst" and "objimmutable" to suggest that
the object data structure (hence the "obj" prefix) is immutable or
const. This was a compromise between brevity and descriptiveness. I
suppose they could also go "constobj" and "immutableobj".
Personally, I like better the feel of const(Object)ref than any of these
keywords. For one thing, it doesn't require any new keyword.
I would argue that adding new keywords is a better way to go because
we're not giving the "ref" keyword two distinct but very subtly
different uses.
For
another, it's perfectly in line with how you do it for pointers. Also,
it'll work for 'shared' and 'inout' too (once 'inout' works properly).
Are you saying that objconst and objimmutable would NOT work for shared
and inout? Why is that?
Working like pointers has other advantages too: it allow you to
transpose your understanding of type deduction and type matching in
templates and is-expressions freely between pointers and objects
references. Making the syntax different adds a barrier to applying your
experience of one to the other, this barrier simply does not exist with
const(Object)ref because the syntax is similar enough to const(S)*.
Another reason why the objconst/objimmutable syntax is better than
"const(Object)ref" is that it requires fewer tokens to parse and to
type -- this makes it easier to read:
const(Object) ref a; // 5 tokens in the type
objconst Object a; // only 2 tokens
Easier to type, granted. Easier to read, I'm not so sure; mimicking the
existing syntax for pointer makes things more coherent.
Easier to parse, I'm not too sure about that either, but it's quite
irrelevant anyway. What's difficult is implementing the corresponding
semantics in the compiler. The main reason being that, unlike the common
perception people have, it's only the compiler backend that deals with
class types the same way it deals with pointers. Type attributes (const,
immutable, shared, inout) are enforced in the frontend, and the frontend
has no separate type for an object and an object reference, and thus no
way to attach attributes to the reference separately from the main
object type. As the entirety of the frontend is written with that
assumption in mind, it's hard to overcome without rewriting a very big
portion of the code.
When I said easier to parse, I meant by human eyes. Sorry, I should
have made that clearer.
Now, I figured a way around that, one that Walter will hopefully accept
once he find enough time to review my patch. If he thinks another syntax
(such as yours) is more appropriate, it should a pretty trivial change.
But my preference remains with const(Object)ref.
I still like my proposal best, BUT I would rather see your syntax be
selected over mine than for us to be left with no better option than to
use Rebindable to get mutable references to constant object data structures.
Thanks for your input Christopher, and welcome to D.
You're welcome. I'm glad to be joining the D community. Thanks for
taking the time to write a thoughtful reply to my postings.
- - -
For reference, here's my pull request for const(Object)ref:
<https://github.com/D-Programming-Language/dmd/pull/3>.
