Aaron wrote:
> > C<is const> means: "Once declared cannot be *assigned* to".
> >
> > But that doesn't mean one can't *bind* a new value to the
> > variable (which would retain its C<const>-induced unassignability
> > after the binding).
>
> I understand that. I guess what I'm saying is, from a conceptual
> standpoint, isn't it misleading to say that "class Filesystem provides
> a constant called MAXPATHLEN, which is 2048", but then to have
> the class override that and change it to 1024?!
>
> I understand that we can wag a finger at the person who does this
> and tell them that they will have bad luck for seven years.
Or we could provide a trait that prevents it:
my $MAXPATHLEN is unbindable const = 2048;
> I suggest that Perl's internals are very interesting, and certainly
> very important, but features such as constants instance variables
> have meaning to programmers, and if their application in Perl does
> not conform to expectation, programmers are likely to have a
> rougher time.
But that's the point. We're working hard so that behaviours *will*
conform to programmer expectation. It's just that (as C++ discovered to
its detriment) a single reasonable expectation of the behaviour of
C<const> is impossible to find.
And such an expectation (if it existed) would have co-exist with reasonable
expectations for the behaviour of binding. To me C<is const> means: "the
*value* stored in the memory implementing this variable cannot be changed".
Which doesn't preclude rebinding the variable to some *other* memory.
But others have a different (and equally reasonable) interpretation of
C<is const>: "the value I get from this variable will always be the same".
Now it may well be that Larry will prefer your interpretation and C<is const>
will preclude rebinding as well as reassignment. But then, I fear, your
reasonable expectation of per-object constants could only be approximated
by the constant (but rebindable):
class Demo;
my $.MAXPATHLEN;
method INIT ($maxpathlen) {
$.MAXPATHLEN := +$maxpathlen;
}
Damian
