[Twisted-Python] Transporting pb.Copyable classes?
jasper at peak.org
Tue Apr 20 21:44:40 EDT 2004
On Wed, 21 Apr 2004 exarkun at divmod.com wrote:
> On Tue, 20 Apr 2004 17:48:00 -0700 (PDT), Jasper Phillips <jasper at peak.org> wrote:
> > On Wed, 21 Apr 2004, Andrew Bennetts wrote:
> > > On Tue, Apr 20, 2004 at 04:20:32PM -0700, Jasper Phillips wrote:
> > > >
> > > > I've been passing around instances of pb.Copyable classes for some
> > > > time, registering them via pb.setCopierForClassTree()... However,
> > > > this doesn't allow me to pass the classes themselves.
> > > >
> > > > I dug around in jelly and found
> > > > jelly.globalSecurity.allowInstancesOf(), which seems to do what I
> > > > want, but makes me nervious as it's pretty buried...
> > > >
> > > > Passing classes seems like a reasonable thing to do, but now I
> > > > wonder if there is some reason that jelly doesn't allow it (except
> > > > via a buried method call)? Or is this just an accidental
> > > > misfeature?
> > >
> > > Why not just pass the name of the class, and unserialise that as
> > > appropriate?
> > >
> > > I'm not a PB expert (or even close), but I always lean towards passing
> > > data rather than code (or code-like things like classes) over remote
> > > method calls when I can :)
> > That's certainly feasible, but then I have an extra unserialize step
> > cluttering my code as the classes passed have attributes I want to access.
> > In general I'm passing game state which exists naturally as code, and while
> > I could always serialize and unserialize it, why bother if I don't have to?
> > Plus, isn't unserializing classes based upon their name exactly what jelly
> > does?
> > On the other hand it's debateable whether the things I'm passing
> > _should_ be classes at all (they represent a type of terrain, with
> > statically accessible fields describing their game effects). However,
> > the quality of my code is really a seperate issue.
> Just to be sure I'm reading this correctly, you have something like...
> class Foo:
> bar = 
> someRemoteRef.callRemote('doStuff', Foo)
> where you want 'remote_doStuff' to receive a class object whose "bar"
> attribute is [baz] (or possibly [RemoteReference(baz)], or *something*
> containing baz)? If not, disregard the rest of my post :) Otherwise
Oh no, no mutable state! Purely static data and static methods.
What I have coils down to something like this:
class Terrain( pb.Copyable, pb.RemoteCopy ):
def moveCost( cls, unit ):
moveCost = classmethod( moveCost )
class Mountains( Terrain ):
cost = 6
A bunch of hexes then have their .terrain = Mountains (etc.) I could easily
change this to instantiation the various Terrains, but in my mind that
implies that an instance's state could differ. I'm beginning to think
the distinction is more trouble than it's worth however, and potentially
> You're going to have difficulty using PB with this approach. PB can
> serialize classes, but it does so in exactly the way Andrew described:
> it looks up their name and sends it, and the other side turns the name
> back into an object. Any mutable class state you change on one side
> will *not* be reflected on the other side.
This is exactly what I want for these classes.
> I'd recommend moving your mutable state off these class objects and onto
> instances of some sort. Otherwise, you will have to implement special
> jelliers/unjelliers for the class objects you want treated specially.
Sorry for the confusion! I really didn't mean to bring my code into the
discussion, I just want to know whether passing class objects is supposed to
work, because it doesn't for me (i.e. I get Insecure Jelly exceptions)
without tweaking inner bits of Twisted.
More information about the Twisted-Python