Re: Re: names for init block keywords?

--- Paul Prescod <[email protected]> wrote: > Mukhsein
Johari wrote:
> 
> >...
> > I think init: is confusing. How about initial: ?
> > I'd prefer something like onFirstCall: but that
> might
> > be too long for a keyword. This keyword should be
> on
> > that reinforces the idea that the following block
> is
> > run on the first call only. (for original as well
> as
> > inheritor code maintainers, not to mention
> newbies)
> 
> As per your example below, the code is NOT called
> "on first call". It is 
> called immediately after the function is defined.

Paul, I think you've misunderstood.

The above and below are 2 different things! Have a
look at the proposal. This is about 2 different
keywords for 2 different uses.

Above is about init:. init: is about running some code
at the first call (and only at first call) of the
function, not at function definition time.

Below is about outer: and that is supposed to 'run' at
function definition time - which is why Mark wanted
outer. (it's outside of the def) Hence the two below
are equivalent. Hence I said "On a related note", it's
related, not the same thing.


> > On a related note, from the wiki:
> > -------------------------------------
> > def f(x,y,z):
> >     """f is a long boring function"""
> >     outer:
> >         f = resCache(logger(f), cacheSize = 500)
> >     blah blah blah
> > <pre>
> > 
> > This would be functionally identical to ...
> > 
> > <pre>
> > def f(x,y,z):
> >     """f is a long boring function"""
> >     blah blah blah
> > f = resCache(logger(f), cacheSize = 500)
> > ---------------------------------------
> > 
> > If the two are equivalent, why add the uneeded
> sugar?
> 
> All sugar is unneeded so the word unneeded is
> redundant.

I said it for emphasis.

> But sugar helps people to make programs that are
> easier to read and 
> write. This particular sugar is designed to solve
> 

imho, the outer: keyword does not make it easier to
read or write. It just adds bulk (to the language)
that doesn't seem to add all that much value.

> > What's wrong with just doing the latter? Isn't it
> > clearer that you're actually executing code as
> opposed
> > to defining in the latter as opposed to the
> former? 
> 
> Actually, in Python, a key goal is to make the
> feature look declarative 
> rather than procedural. Mark has taken a different
> route in Prothon. I 
> think I mildly prefer the declarative Python style
> but the Prothon model 
> is more explicit about what it is really doing.
> 

I'm not so sure that that's true.

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html