[Bf-python] bpy.libraries modules (was "Adding a new way to deal with libraries")

Martin Poirier theeth at yahoo.com
Fri Mar 16 21:48:31 CET 2007


--- Ken Hughes <khughes at pacific.edu> wrote:

> (1) re-implement all the methods/attributes in the
> Object code, but with 
> just a little test to check whether this proxy has
> been made into a real 
> object,
> (2) use the "old style" python API, which lets us
> intercept method and 
> attribute names and examine them, so we can call the
> real Object 
> attribute/methods when the proxy is real,
> (3) do something sneaky and actually change
> self->ob_type from the proxy 
> to a real object when the object is linked to a
> scene.

3 is probably the most promising (assuming it is safe
to do that, which I'm kinda thinking it's not). If it
does work, then the pseudo-object would really become
an instance of Object (which will therefore be able to
be passed as parameters to all the methods/functions
that accept objects).

1 and 2 have the problem that the pseudo-object, while
being able to acts as an object regarding attribute
access and methods can never really be one unless we
change all the methods/functions accepting objects as
parameters to accept pseudo-objects too. (and
moreover, of the two, 1 is especially heavy to
implement).

If 3 isn't possible, then I'd suggest we make the
pseudo-objects as distinct from objects as possible
with very little practical use apart from linking them
to a scene. Then, scripters won't be tempted to use
the pseudo-objects for what it's not.

Martin
PS: As an asside, a materialization proxy is a pattern
often use in OO database API to represent data-links
to objects that haven't been loaded from the DB yet.


 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL



More information about the Bf-python mailing list