[PEAK] PyProtocols --

[Phillip J. Eby]

At 11:32 PM 2/16/04 +0100, Gabriel Jägenstedt wrote:

>I can't seem to find any mention of any ICompositie, would you mind
>pointing me in the right direction? What is it?

IComposite was supposed to be an interface that you would define that means 
that an object is composed of parts, i.e. has a 'parts' attribute and 
whatever other things you might want a composite object to do.  It's not an 
existing interface anywhere that I know of.


>I notice that you use Interface not just for documentation but actually
>providing a usefull function. I like it a lot and especially the fact
>that we pass in commandObj, or in the case of PUB I belive an instance
>of Command. Command supplies all and more information one could want
>about a command.

In general I'm not that keen on putting real functionality into an 
interface, or at least the few times I've actually done it (e.g. 
peak.util.fmtparse) I haven't been all that happy with the results.  But I 
know some people like it and I wanted specifically to support that approach 
in PyProtocols.

Anyway, it seems like it should work for your intended purpose, so I used it.


>oh and why on earth is there a parameter klass? I've seen it before
>around here, but I can't figure it out. Is it a strange word for self
>and if so why?

No, it's a strange word for "class".  :)  The first parameter of a 
classmethod is the class it's being called from.  So, for the following:

class Something(object):

    def someMethod(klass):
        print klass

    someMethod = classmethod(someMethod)


Doing 'Something.someMethod()' will print '<class __main__.Something>', or 
something like that.

Notice that we are *not* making an instance of the class and calling the 
method, we're just calling the method directly on the class.



> > So, each object gets an iterator that yields the next object in the
> > post-order traversal that implements the desired interface, or if
> > there are no candidates remaining, it returns the default
> > implementation provided by the interface itself as a class method.
> > Each invoked method has the opportunity to call
> > 'chain.next().whatever(chain,...)' to get the result of a sort of
> > "super" call.
> >
> > So, if you need to implement weight, you could call
> > 'invoke(ob,ICarriable,"getWeight",commandObj)', and each object's
> > implementation would look like:
>
>Correct me if I'm missing something but how can we possibly test the
>truth of invoke when it has no return statement? I was under the
>impression this will always become false..

Oops.  The last line of 'invoke()' should read:

     return getattr(first,methodName)(chain,commandObj)

That is, the 'return' was missing.



> > For openability, you'd have a door implement IOpenable, but if it
> > contains a lock, the lock would get the chance to refuse to be opened,
> > unless it was unlocked, in which case it would call
> > 'chain.next().open(chain,commandObj)', thus invoking the door's open()
> > method.
>
>Now this is where I'm unsure or rather I'm very unsure about several big
>design issues. It looks like We'll be needing a lot of adapters. Or
>maybe not, when it comes to many adapters are most likely game specific.

Actually, the design as I described it has no adapters *at all*.  You 
simply declare that a component implements something, if it implements 
something.  That's not an adapter.

Now, it's possible that you might define some adapters between certain 
interfaces.  Like, if you need to be able to support "waving a magic wand", 
you might want to have a IWavable interface, and define an adapter from 
ITakeable to IWavable, so that anything that can be picked up can get an 
appropriate message like "You look rather silly waving the X", but the 
default implementation in IWavable itself says "You can't do that."

That's a rather silly example, but I just want to show where you'd be more 
likely to have an actual adapter, as opposed to just assembling composites 
by using components.


>If we just provide a decent amount of good and sturdy adapters and
>interfaces it should be fairly simple to create adapters for game
>authors. I'll just have to figure out some mechanisms to make creation
>simple. A nice and big objectlibrary should be of much help.
>
>The biggest problem will be to determine what should be Interfaces and
>what should be adapters.

Huh?  You've completely lost me.  You define an interface for each group of 
related actions you need to carry out.  And you define a component for each 
specific behavior(s) you want, like creating a "lock" component that can be 
added to doors or books or whatever you'd like to be able to lock.