[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