Re: extensions to settor variables?

[friedman@cli.com (Noah Friedman)]

>I mean, you don't really want to have:
>	- a function called when you dereference anything, or

I think you do.  Even in an object system with gettor functions, I want the
fact that a gettor is being invoked to be explicit.  I don't care deeply
about the particular syntax, but I want to look at the code and know that
an *action* is being performed to fetch the value of something, and not
simply a sort of passive inspection of state.

As for es, which doesn't provide records or objects of any kind, the idea
of a "discipline function" for a variable seems gratuitous anyway.  One
expects a variable to change value by explicit assignment (or possibly as a
side effect of some function).  But one does not normally expect them to
change just by referencing them!  Settors in es already potentially confuse
the issue, which is why I think any program that uses them should be
judicious about the number of variables that are simple aliases or
different "views" of the same data (e.g. `PATH' and `path').  Anything
beyond that is probably abuse.

Anyway, I think I'm straying from the point, and I don't really want to get
into an argument about language semantics, especially since I have only
limited and empirically-acquired knowledge.

But I do want to recommend that people be conservative about what new
features are added to es, if any.  When I first joined this list, I
remember that the general attitude was that there were features that should
be removed.

I think it would be a lot more useful to think about cleaning up the
semantics of existing features, such as the globbing/redirection problem.
I don't have any ideas yet, because I keep worrying that if I don't
vehemently shoot down the idea of "discpline functions", someone will add
them.  :-)