Why we will use obj$func() often

[David MacQuigg]

On Thu, 22 Apr 2004 18:28:37 -0700, Erik Max Francis <max at alcyone.com>
wrote:

>Mark Hahn wrote:
>
>> Well, I do tend to exaggerate a bit.  I can understand it when I study
>> it,
>> but in everyday coding it does not roll off my fingers.  Also, it is
>> possible to design something new without understanding the old.
>
>It is _possible_.  But it is not a very good idea.
>
>> I am serious when I say I think that Python has headed off into
>> egghead land
>> a bit and I feel that keeps a lot of people from switching to it.  I
>> think
>> that this heady stuff scares them off.  I really am trying to make
>> things
>> simpler in Prothon.  Now, whether I can succeed or not is another
>> question.
>> Only time will tell.
>
>Other than the basic premise of Prothon, every single decision I've seen
>you make (or consider) looks wholly stylistic, awkward or even arcane,
>and the opposite of the one I, or I think Guido, would have chosen. 
>Being a fan of Io, I think prototype-languages are interesting.  Even so
>far, I lost interest in looking at the actual main feature of Prothon,
>after seeing all the extra baggage that was brought on in unecessary
>stylistic changes.
>
>Seriously considering every single possible proposal is not
>constructive.  Without a strong sense of what the language should look
>like, Prothon is going to continue to look more and more like Perl. 
>It's already most of the way there.

Mark: """ 
   Please hold off your ad hominem attacks until the product is
   designed, thank you very much. """

I would take this as constructive criticism, not an ad-hominem attack.

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

Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent.  Then, we can see if the benefit is worth the extra
syntax.  We spend far to much time debating syntax without a clear
benefit in mind.  Show us a nice closure.

-- Special syntax to indicate binding of functions.  Python solves
this problem neatly, at the expense of some implicitness.
bound_func   = cat1.func  # cat1 is an instance
unbound_func = Cat.func   # Cat is a class
Prothon's insistence on having not a trace of class-like behavior has
opened a can-of-worms.  Iron out the wrinkles on one place and they
pop up in another.

== Benefits of Prothon ==

In spite of these criticisms I do believe Prothon has made a big
contribution in the *simplification* of classes. There are also some
smaller items worth looking at ( break tags, uniform syntax for
mutation!, boolean?, ... )

-- Dave