[IPython-dev] App's, Components and refactoring
Wed Jul 29 14:36:14 CDT 2009
Thanks for comments!
> c = MyComponent() # this build it with class defaults
> > c.configure(config) # The App or parent component passes the config to
> > object to the component to override the defaults
> > c.freeze_config() # This tells the component that config is done and that
> > 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
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
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
> > look something like this:
> > rc = Component.find_component_runtime('prompt1', Prompt) # get the
> > 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
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev