unpaintable (the solution to logical const)

[Bruno Medeiros]

Jason House wrote:
> Janice Caron wrote:
> 
>> On 04/04/2008, Jason House <jason.james.house at gmail.com> wrote:
>>> Most of the later terms seem confusable with non-changing data instead of
>>> type. I like the term isolate the best.
>> Yeah, it's true - the thing that gets frozen is the /type/, not the
>> /value/, so any word that is a synonym for const would be s-o-o-o-o
>> confusing.
>>
>> I recently suggested to Steve that we use an adverb instead of an
>> adjective
> 
> What about always?  It's short and seems to work pretty well.
> 
> always invariant C x;
> always const C y;
> always C z;
> 
> My only concern is that stuff like "always int x = 5" could be confused as a
> constant.

All of those suggestions suck :P ... By those, I mean 'allways', 
'frozen', 'permanently', Knud's suggestions , Paul's suggestions , etc.

Everything you are trying to describe is a *consequence* of the 
attribute you are trying to describe. (the consequence being that the 
type remains the same and is not affected by const/invariant of the 
owning class/struct)
But it is not really the nature of attribute. What *really* describes 
the attribute we want here?
'external'! As in:

   external invariant C x;
   external const C y;
   external C z;

The attribute readily describes that such member is not part of the 
logical state of the owning class/struct. (It may even be possible to 
reuse this for other things other than const/invariant.) I know that 
this issue is very subjective, but c'mon, doesn't it make much more 
sense than other suggestions?

(and yes, if we're anal about keywords, we could use 'extern' instead of 
'external')


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D