Why we will use obj$func() often

David MacQuigg dmq at gain.com
Fri Apr 23 20:59:06 EDT 2004


On Fri, 23 Apr 2004 16:36:15 -0700, "Mark Hahn" <mark at prothon.org>
wrote:

>
>"Donn Cave" <donn at u.washington.edu> wrote ...
>
>> What you're doing there looks to me a bit like Objective
>> CAML's ref type.  "a = ref 0" is a mutable container for an
>> immutable integer.  It's just syntactic sugar for a mutable
>> record;  the sugar is the assignment a := 1, and then there's
>> some special dereference notation -- a := !a + 1, something
>> like that, I forget.
>
>I'm not doing anything nearly that complex.  &var just gives access to the
>outer closure scope and directly accesses var in that scope, just like
>accessing a global variable.  It isn't just syntax sugar for var[0] because
>it has none of the list overhead associated with the var[0] kludge.  & just
>tells the compiler where to find the variable, just like capitalized
>variables in Prothon say to find them in the global space and .var says to
>find var in self.
>
>The whole point is to make things simpler, more readable, and more
>efficient, but when people see the & symbol they somehow automatically think
>it's complex.  Maybe my mind doesn't work like everyone else's.

I think you are misunderstanding the objections to the proposed
features.  I see on this thread very little knee-jerk reaction to a
new symbol.  Its the accumulation of symbols and special syntax for
little problems that will cause a big problem.  In my first post on
this thread I pointed out the problem:

-- Perl-like syntax:
Special symbols and capitalization to indicate variable scope,
closures, dynamic variables, etc.   
   local, Global, .x, ^x, X, &x, x, @x

Yes, I did use the P word, but my criticism is *not* over the choice
of symbols.  What I worry about is the complexity which will result
when all these little features become commonly used, and students are
accessing variables all over the place instead of thinking about the
structure of their programs, and figuring out how to solve a problem
with simple syntax and structures.

Once you add something like &x to a language, you can never take it
out.  Not only will you break existing code, but you will break the
hearts of all those who now cannot write a program without that
feature.

I'm not trying to give you a hard time. I just don't see the value in
providing elegant syntax for obscure problems like &x.  I'm not saying
the value isn't there.  I just don't see it in what you have posted so
far, and I'm a bit put off by your statement that you don't have time
to put together a use-case.

If I were you I would postpone all these embellishments, and the
associated discussions, and focus on the one really good thing in
Prothon, your simplification of classes.  If you can do that in a way
that doesn't make migration from Python difficult, you will have a
winner.

-- Dave






More information about the Python-list mailing list