Re: Method binding confusion

From: Dave Brueck (dave_at_pythonapocrypha.com)
Date: 05/22/04 

Date: Sat, 22 May 2004 14:10:28 -0600
To: "python-list" <python-list@python.org>

David MacQuigg wrote:
> All functions and methods *should* be unified. See the section
> "Unification of all function forms" in PrototypeSyntax.doc at
> http://www.ece.arizona.edu/~edatools/Python

That's cool that you've taken the time to gather your thoughts onto some pages
that anyone can view. One thing that might make them even more useful to
illustrate your point would be to have a page that shows unification in the
absense of the other changes you're proposing (in the page listed above, the
reader has to set aside prototypes and miscellaneous syntax changes and try to
focus on just function/method unification).

Also, such a page would really benefit from a few simple but uncontrived
examples of how things work now, and how they'd work after your proposed
changes. From reading that page, I'm not entirely sure how the tasks I
currently solve with bound methods, unbound methods, static functions, etc.
would work under the new system - many people learn best by example, but that
page illustrates (as far as I can tell) how only one method of calling would be
affected, and the example is obscured by unrelated syntax languages.

So, for example, find the two or three most common use cases of unbound
methods, and simplify the examples to make them concise but not so far that
they becomes overly contrived (in the math example you've posted a few times, I
have a hard time imagining why I'd ever want to do that, so to me it's not very
compelling). Show the code for the implementation as well as how the calls
happen. Then show the same for how things would look after your changes. Repeat
this whole process for all calling conventions that would be affected.

Short of this, the ability to convince people will be limited - the problem you
cite doesn't seem to affect me much in day-to-day development, and I haven't
seen it be a big hangup for people learning the language (most don't
notice/care, the rest get past it almost instantly with the simplest of
explanations). If on top of that it's also unclear to me how I'd get the same
things done if the language were changed (and it _is_ unclear to me), then it's
hard to maintain interest in this topic.

Good luck!
-Dave

Relevant Pages

  • Re: OT: compilers, interpreters, and VMs
    ... not too long ago (language rankings and so on). ... we don't need to keep the compiler as a one-time only thing in terms ... doubles as raw types, in their various sizes, on the stack. ... reconcile the desire to use C calling conventions with the desire to ...
    (comp.lang.misc)
  • Re: Which lean C compiler for 32-bit OS development
    ... with the language the way it is designed, ... For just about all the C programming I have ever done I have had to ... interface with no other programming languages. ... the calling conventions of the C compiler I choose. ...
    (comp.lang.c)
  • Re: Variables allocated on stack
    ... _two_different_ calling conventions in his compiler with the added ... binary interface becomes useful. ... gcc for Windows says 32, ...
    (comp.lang.c)
  • Re: How to tell if a theory is a good one
    ... >> The proof of Fermats last theorem I ... >> language of PA eg Riemann surfaces and elliptic and modular functions. ... > It's unclear from these comments whether or not you accept the proof ... > of FLT. ...
    (sci.physics.particle)
  • Re: How to tell if a theory is a good one
    ... >> The proof of Fermats last theorem I ... >> language of PA eg Riemann surfaces and elliptic and modular functions. ... > It's unclear from these comments whether or not you accept the proof ... > of FLT. ...
    (sci.physics)