const

[Scott S. McCoy]

I don't think types should consist of compound phrases.  viewof sounds
like a method name, not a part of the primitive type system.  If you
forget about the existing const in D 1, const beats out viewof on
several counts:

 1. It's 1 character shorter.  We call it int and not integer for a
reason.
 2. It's one word
 3. It doesn't have a phrase which infers it's some form of translation
viewof(Type) looks like you're creating a view of a type.

That being said, I'm sort of annoyed with the fact that const(type)
looks like a function.  And I'm similarly annoyed with the introduction
of special syntax just so we can use the same phrase to classify methods
that we use to classify storage.  I mean, it makes sense from the
standpoint of static, but it doesn't make sense form the point that
const can be a return value.

const const(Foo) foo (const Foo).

That's just terrible.

>From one angle, it makes sense following the form of static:

private static int _foo;
public static int foo () { return _foo; }

However it's not as natural, since the static keyword is behaving
precisely the same in both of the above expressions.

When you get to const, it stops behaving the same...that is..

class Foo {
    private const int _foo = 123;
    public const int foo () { return _foo; }
}

If I understand the D 2.0 specification as it sits now, these two const
statements have nothing to do with each other, and that's the anomaly.
In the static case a static method has to be static to access a static
member value.  But in the const case, the const method has nothing to do
with the const member value.  methods don't have to be const to access
const member values, and vice verse.  So that const only qualifies that
you can call foo() in the instance of a const(Foo), which is defined as
follows (assuming I understand correctly):

const Foo foo = new Foo();
foo.foo();

So what we've done, it seems...is taken a syntax for one behavioral
class, and applied it to another behavioral class.  And because this has
been done, to retain the constivity of int the above class is invalid,
and you actually must:

class Foo {
    private const int _foo = 123;
    public const const(int) foo () { return _foo; }
}

So what I'm saying I guess is, I feel like the current syntax is kind of
messed up.  I don't care about the keyword, but I do think const is
better than viewof (although "view" might make more sense, but it really
doesn't matter what it's called).  
So with that being the case, what if const was a type annotation.  That
is, what if a more annotative syntax was applied to make a given
identifier const:

private int : const foo;

Either that, or what if atleast to rid ourselves of the disparity, the
const storage class syntax was removed and replaced with that which is
similar to the return value...  The reason I say disparity, is my
understanding is that const on a method only verifies that no values are
modified via the this reference...so I think that means you're
completely allowed to:

class Foo {
    private int _foo = 123;
    public const int foo () { return _foo; }
}

So what if we atleast made the syntaxes consistent between storage and
return values, forcibly:

private const(int) foo; /* You have to say it's const(int).... */
public const const(int) foo () { return _foo; } /* Now atleast the
syntax between the declaration of the identifier and the return value
are consistent */

Similarly, you could always bring back the C++ish method classifications
(they're still around, right?)

public const:
    const int foo () { } 
    const int bar () { }

I don't find them that terrible...so now we have to define const method
types within a special area in the class...that's actually not a bad
idea anyway!  But I'm sure it'll get some blowback.  But I'm not totally
convinced this is a concept that deserves only a new definition of an
old keyword.  Some special syntax seem in order.

Never forget, we introduce punctuation to provide segmentation of
concept.  We do the same thing in programming languages...maybe some new
punctuation is needed to provide a difference between const the member
class and const the storage class.

I dunno, just some ideas.  My beef with const right now isn't the
concept, it's great to have transitivity in const (assuming I understand
it correctly) and hell, adds a lot of power to D for multiprogramming.
Honestly, I don't think nearly as much is gained by having invariants
and have wonder if they provide more than an optimization opportunity
for the compiler.  But still, I think the syntax could use some work.
It feels a little hob-gobbled.  I'm sure there is a much more expressive
way to do this that I haven't thought of or mentioned in this email, but
I'm pretty sure whatever it is we're not doing it.

Cheers,
    Scott S. McCoy

On Sun, 2008-03-30 at 07:58 +0100, Janice Caron wrote:

> 
> 
> 
> 
> Another alternative to view is viewof. As in viewof(T).
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20080330/a2fef017/attachment-0001.html>