Default Value

[Rick Johnson]

On Friday, June 21, 2013 10:57:17 AM UTC-5, Steven D'Aprano wrote:
> On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote:
> >   py> class FuncAdd(object):
> >   ...     def __init__(self, ivalue):
> >   ...         self.ivalue = ivalue
> Notice how you are storing state here? I thought you said,
> and I quote: "When the subroutine is completed, ALL INPUTS
> and local variables are expected to be destroyed. If the
> programmer wants a return value, he need simply ask. Data
> persistence is NOT a function of subroutines!" 
> [emphasis added]
> 
> And yet here you are defining persistent input ("ivalue")
> to the callable subroutine, which is stored as external
> state and not destroyed at the end of the subroutine call:

Because Steven, my dear lad, what i created is NOT a
subroutine, no, it's an object that stores state and is
callable. Each call to the object is merely a request to
mutate and then return it's current state. A subroutine, at
least REAL subroutines (not the snake oil that Python is
selling) do not have state. 

Real subroutines merely:
 1. Optionally take inputs
 2. Execute a body of code (which could have side effects, 
    but which is NOT persistent!)
 3. Optionally return output

That's it. If your problem requires state persistence, then
you need to move up to an Object definition. Use the correct
tool for the job dammit!

> >   ...     def __call__(self, numeric):
> >   ...         return self.ivalue + numeric 
> >   ... 
> All you have done here is define a subroutine with state,
> precisely the thing that you say subroutines must never
> have. 

It's Okay to carry state EXPLICITLY, it's NOT okay to carry
state IMPLICITLY. My implementation is correct, Python's is
not. 

Besides, encapsulated state is one of the fundamental
principles of OOP programming, along with interfaces; and
i've satisfied both! The mutable is protected from the world
by an object, and the object allows manipulation of the
mutable via an interface.

But unlike Python's limited implementation, my approach is
scalable. I can change the interface, i can add more
functionality, i can do anything i want.

 "I am the Lizard King, and i can do, well ANYTHING!"
 
However, with Python's limited approach, i'm just a slave to
the implementation. I'm forced to follow estoeric rules with
no chance of scalability.

  ########################################################
  #                   Moral of the Day                   #
  ########################################################
  # You should only use SUBROUTINES for executing        #
  # subprograms requiring stateless transactions.        #
  # Alternativly, subprograms requiring persistant state #
  # transactions should wield the power of a custom      #
  # object defintion -- or you can use the               #
  # global+subroutine method if encapsulation is not     #
  # warrented.                                           #
  ########################################################
    
But in any case, following this advice will ensure less bugs
and more maintainable code than Python's current
implementation of lunacy.

> What you haven't done is define a function which takes a
> default value that can be overridden when called. 

Oh, you mean like this?

  py> class Func(object):
  ...     def __call__(self, arg=0):
  ...         print(arg)
  ...         
  py> f = Func()
  py> f("pwned")
  pwned

> Your argument is invalid.

My argument is not invalid, i just figured i did not need
wipe your bum for you, "Homer".  ~(_8^(I)