prototypes in Python [was: what is good in Prothon]

[has]

michele.simionato at poste.it (Michele Simionato) wrote in message news:<95aa1afa.0404280120.30176ca9 at posting.google.com>...
> So far, I have not installed Prothon, nor I have experience with Io, Self
> or other prototype-based languages. Still, from the discussion on the 
> mailing list, I have got the strong impression that you do not actually
> need to fork Python in order to implement prototypes. It seems to me
> that Python metaclasses + descriptors are more than powerful enough to 
> implementing prototypes in pure Python.

"Metaclasses" and "prototypes"... <ouch> Now there's two words that
should NEVER appear in the same sentence (or even on the same planet,
for that matter). Metaclasses may be Manna for complexity junkies, but
they're nothing but a viciously bad joke imposed by those who ought to
have known better and perpetuated by those who never will.

One of the great advantages of proto-OO is it shows up metaclasses for
the ludicrous code masturbation they are. As to why they're still
here, lingering like the stench of long-dead rat from under the floor
when they should've been shitcanned years ago... well, draw your own
conclusions. (Two words of my own: "politics" and "religion".)

[BTW, this is a totally generic rant; please don't think it was meant
personally! It's just that, well... if there's two words guaranteed to
push ALL my wrong buttons, those two are it.<g> Anyway, <Rant Off> -
and let's get back to our scheduled program...]

--

As far as doing proto-OOP in Python is concerned, you can, but it'd be
a bit like doing OOP [of any flavour] in C. i.e. Not much fun. You
basically have to roll your own structures and runtime support, and
provide syntactic sugar via some kind of pre-processor or compiler
extension if you want it to be halfway decent for users to code in.

Here's a very simple, incomplete and very naive example to give you an
idea of how you might start attacking it:

#############################

class _DelegateStub:
    """Terminates the delegate chain."""
	
    delegate = None
    copy = staticmethod(lambda:_DelegateStub)


class Object:
    """This class defines the generic proto-OO object 'type' used to
create all objects."""
	
    delegate = None # kludge
    _dict = None # kludge
	
    def __init__(self):
        self.delegate = _DelegateStub
        self._dict = {}
	
    def __getattr__(self, name):
        if self._dict.has_key(name):
            return self._dict[name]
        else:
            return getattr(self.delegate, name)
	
    def __setattr__(self, name, value):
        if name in ['delegate', '_dict']:
            self.__dict__[name] = value
        else:
            self._dict[name] = value

    def copy(self):
        """Clone this object."""
        new = Object()
        new.delegate = self.delegate.copy()
        new._dict = self._dict.copy()
        return new


# Creating a new object from scratch:

# Define object 'foo'
foo = Object()
foo.a = 3
foo.b = 3
foo.multiply = lambda target:target.a*target.b


# Do stuff with object (note: due to lack of runtime magic, user  
# must pass the target object to an object's 'method' themselves):

print foo.a, foo.b # --> 3 3
print foo.multiply(foo) # --> 9


# Creating a new object by cloning an existing one:

# Create object 'bar' by duplicating object 'foo'
bar = foo.copy()

print bar.multiply(bar) # --> 9

# Object 'bar' can be modified at will:

bar.a = -5
bar.c = 'hello world'

print bar.c # --> 'hello world'

print foo.multiply(foo) # --> 9
print bar.multiply(bar) # --> -15


# Behavioural composition through delegation:

# Create object 'zib' containing method 'power' with 'bar' as its
delegate
zib = Object()
zib.power = lambda target:target.a**target.b
zib.delegate = bar

print zib.c # --> 'hello world'
print zib.power(zib) # --> -125

#############################

Obviously, implementing a complete proto-OO system in and atop
Python's native class-OO system is going to be both tedious to use
(due to lack of syntactic sugar) and slow to execute (as it's all
interpreted Python code). Which is why it makes sense to start from
scratch as Mark is doing, or at least fork an existing language and
seriously strip down and rebuild it (which is a thought that's
previously crossed my own mind, though I lack the time, patience and C
skills to tacke such a project myself).