Re: Function once: concern

Mark Hahn wrote:

>...
> The once section has nothing to do with this problem.  This is a problem of
> using static vars in different functions with the same name.

Why not have a "func." prefix like "self." or "outer.".

> So far we have one vote specifically for once and your one vote specifically
> against once.  We have several votes for the overall proposal.  I haven't
> voted.
> 
> The one vote for is a usage case.  Your vote against is a good ole
> complication argument and nothing more.

Sorry, can you point me to the use case? Can you show me what the code 
looks like with the once: feature and without?

> By the way, what you two are calling init is now "outer" and what you are
> calling once is now "init".  I never agreed to call them init and once.  I
> might agree to call them "outer" and "once".

In my opinion this feature's syntax is straying too far away from the 
original use cases.

In statically typed languages there are many declarations on functions 
and arguments that attach metadata and/or wrapper behaviour on 
functions. Modern statically typed languages like Java and C# allow 
user-defined annotations that might releate to things like threading or 
persistence or transactional integrity, etc.

Dynamic languages would like to have similar _declarations_. By virtue 
of the way dynamic languages work, one can use a procedural syntax to 
mutate (a.foo=bar) or wrap (a=wrap(a)) objects. This is a little bit 
like using a struct pointer as a vtable but it works.

There are a few problems with using procedural syntax. But the most 
serious is that it can historically only be done AFTER the functions 
body has ended which seperates the function name by potentially hundreds 
of lines of code from the function declaration.

The other problem with the procedural syntax is that it arguably 
overgeneral, verbose and harder to read. Compare the statically typed 
language:

synchronized foo(...){
    ...
}

def foo(...):
   ...
func = synchronized(func)

An extra line, more tokens and more keystrokes in they dynamic language 
than in the statically typed language -- a reversal of usual patterns! 
The dynamic language has also shifted the focus. THE FUNCTION IS 
SYNCHRONIZED. Not "The function should be wrapped with a synchronized 
wrapper."

Now in Prothon we are proposing to call the keyword "outer". Now we've 
gone even farther in obscuring the purpose of the feature. We're 
declaring the SCOPE in which it operates rather than what it is intended 
to do or when it is intended to be used.

Anyone looking at the feature now will naturally ask: "Why not just put 
the outer scope stuff outside the function?" The syntax  for the feature 
has evolved so far away from its use case that it is no longer clear 
what the use case originally was!

I'd encourage everyone to take a look at the examples in PEP 318.

http://www.python.org/peps/pep-0318.html

In my opinion, the keyword "outer:" is misnamed and overgeneralized. I 
prefer Python's declarative approach.

  Paul Prescod