Larry Wall writes:
> Another question is whether a class containing methods containing
> "has" would be confusing. The $s vs $.s distinction seems to help
> a bit there. That would seem to imply that
>
> class foo {
> has $s;
> has $.t;
> }
>
> declares a class attribute vs an instance attribute. But I don't
> really like using the same keyword for two different scopes. And
> I'd rather use the $s vs $.s distinction to indicate whether
> accessor methods should be autogenerated, if we even allow "has $s".
>
I can think of class attributes as persistent environment for
methods ( just code ) inside it .
its interesting that the problem we are discussing is just that -
supply a way to specify persistent environment for subroutines(s) (
and probably any closure ) -- but dont call it class ( and surrounding
block is also sort of nameless class ???).
its interesting that central to the objects is persistent data that
each object carries with it -- and code is in some sence secondary --
only a way to manipulate that data.
now, subrutines (not methods ), because they are not explicitely
associated with particular data are just code . they are "born" every
time they are called and die as soon as they finish. they dont have
state variables. and persistent otside environment is the only way to
keep this state.
probably its right that every persistent piece of environment for the
nearby subroutines should
be a class.
somehow this polarity between data and code is disturbing to me .
anyway -- practical suggestion :
class foo {
env $s;
has $.t;
}
sub foo() {
env $s ??= 0;
$s ++ ;
}
> Still, if anything that is not a class considers itself to be a
> class with a singleton object, then the distinction between
> class variables and instance variables is moot, and "has" could
> be taken to refer to that singleton object's values.
>
probably any block have to be able to have its private persistent
environment . and this is how code can make its step toward data.
arcadi
