[Twisted-Python] Transporting pb.Copyable classes?

Jasper Phillips jasper at peak.org
Wed Apr 21 10:57:47 MDT 2004


On Wed, 21 Apr 2004, Samuel Reynolds wrote:

> At 2004-04-20 06:44 PM -0700, you wrote:
[snip: my description of static classes used for Terrain]

> How about making Mountains, Plains, etc. Singletons?
> Then, instead of assigning hexCellInstance.terrain=Mountain,
> you assign hexCellInstance.terrain=Mountain() (note the
> parentheses!). At that point, each cell.terrain is an object
> reference instead of a class reference and (IIUC) should
> remote-copy properly.

I have considered Singletons, but don't see what advantage they provide.
They basically do the same thing as static classes in this case, except with
more code and IMHO less transparency.  Perhaps if these Terrain classes had
some mutable state, but they don't.

> Caveat: I've not used pb; this is based on my *very* weak
> understanding (misunderstanding?) of it. In particular,
> I don't know how pb/copyable would interact with a singleton.
> I would *expect* that the remote unserialization would
> (eventually) invoke Mountains.__call__ and get a reference
> to the corresponding singleton on the client side.

I suspect singletons might have some trouble with jelly, unless it has some
wacky special case for realizing a passed singleton instance should be
equivalent to the corresponding remote singleton instance, which may or may
not already exist.


All this seems to me like frantic contortion to avoid a bug in jelly.
Shouldn't it be able to translate passed class objects into the remote
version, provided they have been properly registered?  Is there some reason
why not that I am missing?

I appreciate the code suggestions, but basicaly I just want to know whether
this is expected behavior, or whether I should post a demonstrative test
case and suggest a fix.

-Jasper





More information about the Twisted-Python mailing list