Unification of Methods and Functions

[David MacQuigg]

On 11 May 2004 18:54:56 -0700, moughanj at tcd.ie (James Moughan) wrote:

>Sure; you have to have some understood conventions.  In effect that's
>all any higher-level programming language than assembler is.  IMO, in
>the case in point, the explicit self makes OO easier to undersstand;
>YMMV, of course, as it does with Dave. :)

I really hate to get involved in this "explicit self" debate, as I
know it has been debated ad-nauseum for many years, but I wish people
would not attribute to me a point-of-view that I do not have.  For me
the "explicit self" is *not* the issue.  I have a slight preference
for .var over self.var or $var, but this is a matter of personal
preference, not an implicit vs explicit question.

My definition of explicit is that you can tell the meaning of a
statement without reference to the surrounding code.  By that
definition all of the above forms are explicit.  They are all instance
variables, and there is no other interpretation.  The choice between
them is a *minor issue*, and I trust GvR to make these choices.

The real issue is whether we can unify all forms of functions and
methods.  This requires we do something different with 'self'.  From a
unification standpoint, an equally acceptable solution is that we add
'self' to *all* functions and methods, whether they need it or not.

The problem with rules like "explicit is better than implicit" is that
some people take them too literally.  Sometimes it seems like quoting
a rule is a substitute for thinking.  We need to balance all these
rules, and add a good measure of common sense to reach the true goal.

My goal is overall simplicity for the syntax needed to solve the kind
of problems that a non-CIS technical professional might encounter.
That includes static methods, but not metaclasses.  That could change
if someone convinced me that static methods are unnecessary or that
metaclasses are essential to solve a real-world problem.  

Meanwhile I'm happy to just watch the wizards play with metaclasses,
and I don't care if their brains explode. :>)  I'm also happy to use
what they develop with metaclasses.  Case in point - Michele
Simionato's prototype module.  This is easy to use, even if I don't
understand how it works.  To me, its like a C module.  I don't feel I
need to understand the internals.

I feel entirely differently about excess complexity in syntax my
students and clients are likely to write or need to understand.

-- Dave