> > Again, forgive me if I missed something in your examples; but it seems like
> > limiting member access catching to non-existant members, misses some possibly
> > useful functionality (?)
>
> Yes, you might be right... but I don't miss this 'possibly usful functionality'
> :-)
Yes-- you get the same effect with empty class wrappers.
> > One final point: it's not completely clear (to me) that we're buying alot
> > here, _except_ in cases where the set of members of a class are not known
> > statically (and even then, we can use get()/set() accessors manually).
>
> Shure yoy can do it manually, but you cannot write a general Client/Server.
> With my Client/Server framework, you can put any object in the server and a
> client using a Proxy it will look the same (for normal calls) as if it is
> local. You don't have to handwrite the calls to the server - it is done by the
> framework! My sample implementation does not cover the case where the client
> gives a mutable object to the server. In this case the server should get a
> Proxy which calls the methods at the client side... That would be just like
> distributed objects under NextStep.
Agreed; see my post/mail.
> The disadvantage is, that you have to know all the methods - and then handcode
> each method. That's a lot of work!
Yes!
BTW, I'm currently working on a Python programming book, in my spare time.
I'd like to include a case study on client/server programming, since it's
becoming such a pervasive thing. It looks like your examples might work
pretty well. Any chance of using your examples in a book? You'd get full
credit, etc. No promises here (I'm not even positive the book will ever
get done at all...), but I'm looking for contributions.
Thanks,
Mark Lutz