[Grace-core] Edited Variable & Constant page

[James Noble]

> I was imagining a different distinction.

OK...

> On 15 Nov 2010, at 23:21, James Noble wrote:
>
>> but I don't understand what a "readonly const" is?
>
> We haven't (yet) figured out how,or if, to have access control on  
> methods.  So I was imagining the Smalltalk rule that fields can only  
> be accessed inside their object.  Declaring a field readonly creates  
> a method that other objects can use to read that field's value; this  
> makes just as much sense for const fields as for var fields.   If  
> the field is private, then there s no such method, and the field can  
> be accessed only from inside the owning object, by using the field's  
> name directly.

OK - that's not currently the way I've been thinking of things.
I was trying to keep all field access (at least) via methods.

I agree we haven't looked at access control. My current thoughts are
to generalise C# metadata / Java @Annotations (and perhaps comments too
are the base case of metadata) and the syntax for access control
(at least) would be in there.  Of course, the *semantics* are another
mess altogether :-)

>> the other difficultly with "field" is that I was hoping to use the  
>> *same* syntax
>> for declaring fields in objects  and locals in blocks.  Here, this  
>> follows
>> Self and Beta (and arguably Simula)
>
> No, Smalltalk used the same syntax to declare locals in methods and  
> locals in blocks.  Fields are declared quite differently (in the  
> message that creates the class itself.)  I don't lnow about self.

yep I know.  Self object literals look like:  (| varslot.  varslot <-  
initvalue.   constslot = initvalue |)
Then in self blocks, say, one can write [ : arg1  :arg2 | varslot.   
varslot <- initvalue.   constslot = initvalue | code]
(the local defs between the two | | are optional).

>> the difficulty with "const" is, well
>> readonly const x = HighlyVolatileMutableClass.new;   // urgh. How  
>> is this const?
>>
> It's const because the binding between x and the HighlyVolatile  
> object never changes.  There is no need to ever read x more than  
> once.   You can cache it safely; if I do obj.x now and obj.x later,  
> I can be sure that they are egal.

The problem is of course saying "HighlyVolatile object never changes"  
- the object itself changes lots;
the point is the name always refers to the same object... yes I know  
you know this, but as with the
arguments for "self" and "method" - these discussions are all about  
the right names
to bias discussions in the right way...

J