[IPython-dev] App's, Components and refactoring

[Brian Granger]

Darren,

Thanks for comments!

> c = MyComponent()  # this build it with class defaults
> > c.configure(config) # The App or parent component passes the config to
> the
> > object to the component to override the defaults
> > c.freeze_config() # This tells the component that config is done and that
> it
> > should complete any remaining init related things.
>
> This seems a bit awkward to me. Why not do:
>
> c = MyComponent(..., config=(config1,config2,...))
>
> and have the component complete any remaining init related things at
> the end of __init__?
>

Very good point.  For the most part, I think we could do this.  But there
are two usage patterns that we sometimes run into that might require a
separate call to configure:

* There are a few cases where we use adaptors, which requires a single
argument __init__ method that takes the object to be adapted.  In this case,
we can't pass additional things into the __init__ method.

* Currently we sometimes create an object with a default config, then use it
a bit and *then* later finish passing it its config information.  But, I
don't like this usage pattern so we could probably get rid of it.

Overall I agree with you that just using the __init__ method is cleaner
though.


I guess I don't understand the motivation for this extra degree of
> separation, why are run-time attributes held by an objects rc struct
> instead of by the object itself? It seems more natural to use
> properties.
>

I think the main motivation is to have runtime objects that have very small
and clean namespaces.  The classic example of the "is-a" approach is
traits.  Just tab complete on a HasTraits instance and you will see what I
mean about a large a non-clean namespace.

But, I agree with you.  We are not inheriting from HasTraits and there is no
reason we can't keep the namespaces of our object clean.


>
> > Components will have some sort of registry and querying system that will
> > allow different parts of IPython to get the runtime api for other
> > components.  This will also be completely independent of IP itself.  It
> will
> > look something like this:
> >
> > rc = Component.find_component_runtime('prompt1', Prompt) # get the
> runtime
> > api for component named 'prompt1' that is an instance of Prompt
> >
> > Once you have one of these runtime objects you can do a number of things:
> >
> > * read its attributes (rc.prompt_string)
> > * write its attributes
> > * setup notifications rc.add_notification('prompt_string', callable) #
> > callable is called if prompt_string changes.
>
> I think you could maybe do all of this with properties. Notifications
> could be handled with a decorator.
>

Yes, properties or descriptors would handle this fine.  We need dynamic
notifications (at runtime) so decorators wont work for this.  But, it is
pretty simple to come up with a basic notification api.  That is the easy
part.



> I agree. It would be confusing trying to figure out whether the
> desired attribute or method is found on the component itself or on the
> rc attr. Maybe I'm just not familiar with any projects that do it this
> way, so the is-a paradigm feels more natural.
>

I think this is an IPython thing that we maybe want to get away from.

Cheers and thanks,

Brian


>
> Darren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20090729/1d257b01/attachment-0001.html>