Implicit conversion to boolean in if and while statements

[Rick Johnson]

On Friday, February 8, 2013 11:48:43 AM UTC-6, Rick Johnson wrote:
>
> [...] 
> 
> So using a /real/ OOP paridigm we would do the following:
> 
> ## START TRUE OOP PARIDIGM ##
> 
> [...snip naive example...]

Actually my example API is littered with artifacts of a python "global function architecture". In a /true/ 100% OOP language most of these "dunder" methods would become interface members of the object.

There is also the question of WHEN to use and WHEN NOT to use the "dunder" naming convention. I actually like the convention myself for clearly defining methods that are called by "syntactic sugar". However, python employs the convention quite haphazardly. 

For example:  
    __iadd__ is called by an expression such as: "1+=1"
    which is translated into: "1.__iadd__(1)"
    
However:
    __repr__ is called by the the global "repr" function
    which is translated into: "obj.__repr__()"
   
I don't like the second usage because i believe this naming convention should be reserved for syntactical sugar only. But i digress...

Here is a better example of Python converted into true OOP paridigm (renaming and removing methods appropriately to fit my logical 100% OOP API).

class Object(SuperType):
    def construct # aka: __init__
    def desconstruct # aka: __del__
    def class
    def delattr(name)
    def doc
    def getattr(name)
    def __new__ # dunder???
    def repr
    def setattr(name, value)
    def size
    def stringify # aka: __str__
    def subclasshook # XXX: dunder???
    def true? # aka: __bool__
    def callable?
    def compare(other)
    def methods
    def instance_methods 
    def hash
    def help
    def id
    def isinstance?(this)
    def issubclass?(this)
    def super
    def type

class SequenceBase(Object):
    # Methods from object are free
    def __add__
    def __contains?__
    def __delitem__
    def __delslice__
    def __eq__
    def __ge__
    def __getitem__
    def __getslice__
    def __gt__
    def __iadd__
    def __imul__
    def __iter__
    def __le__
    def __lt__
    def __mul__
    def __ne__
    def __rmul__
    def __setitem__
    def __setslice__
    #
    # Interface
    #
    slice = __getslice__
    extend = __add__
    contains? = __contains?__
    def length # pka: __len__
    def any
    def all
    def enumerate -> iterator
    def filter(proc)
    def map(proc)
    def max
    def min
    def reverse
    def reduce(proc)
    def sort
    def zip
    

class Sequence(SequenceBase): # aka: list
    # Methods from SequenceBase and Object are free!
    #
    # Interface
    #
    def append(this)
    def count(this)
    def index(this)
    def insert(idx, this)
    def pop()
    def remove(this)
    def reverse
    def sort
 
I'm a bit unnerved by the sum function. Summing a sequence only makes sense if the sequence in question contains /only/ numeric types. For that reason i decided to create a special type for holding Numerics. This will probably result in many complaints from lazy people who want to use only one Sequence type, which holds mixed types, THEN jamb nothing but numeric types into it, THEN have a sum method that throws errors when it encounters a non-numeric type!!! I say, too bad for you. 

Stop obfuscating your code! Of course someone could probably find a legitimate reason to apply a sum method to non-numeric values; if so, then inherit from NumericSequence and create your custom type!

class NumericSequence(Sequence):
    # Methods from Sequence, SequenceBase, and Object are free!
    def __setitem__(item):
        if not item.isinstance(Numeric):
            raise TypeError()
    def __add__(other):
        if not other.isinstance(NumericSequence):
            raise TypeError()
    def __setslice__(other):
        # blah
    #
    # Interface
    #
    def sum -> Integer