Darren,<br><br>Thanks for comments!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
&gt; c = MyComponent()  # this build it with class defaults<br>
&gt; c.configure(config) # The App or parent component passes the config to the<br>
&gt; object to the component to override the defaults<br>
&gt; c.freeze_config() # This tells the component that config is done and that it<br>
&gt; should complete any remaining init related things.<br>
<br>
</div>This seems a bit awkward to me. Why not do:<br>
<br>
c = MyComponent(..., config=(config1,config2,...))<br>
<br>
and have the component complete any remaining init related things at<br>
the end of __init__?<br>
<div class="im"></div></blockquote><div><br>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:<br>
<br>* 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&#39;t pass additional things into the __init__ method.  <br><br>
* 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&#39;t like this usage pattern so we could probably get rid of it.<br>
<br>Overall I agree with you that just using the __init__ method is cleaner though.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I guess I don&#39;t understand the motivation for this extra degree of<br>
separation, why are run-time attributes held by an objects rc struct<br>
instead of by the object itself? It seems more natural to use<br>
properties.<br>
<div class="im"></div></blockquote><div><br>I think the main motivation is to have runtime objects that have very small and clean namespaces.  The classic example of the &quot;is-a&quot; approach is traits.  Just tab complete on a HasTraits instance and you will see what I mean about a large a non-clean namespace.<br>
<br>But, I agree with you.  We are not inheriting from HasTraits and there is no reason we can&#39;t keep the namespaces of our object clean.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
&gt; Components will have some sort of registry and querying system that will<br>
&gt; allow different parts of IPython to get the runtime api for other<br>
&gt; components.  This will also be completely independent of IP itself.  It will<br>
&gt; look something like this:<br>
&gt;<br>
&gt; rc = Component.find_component_runtime(&#39;prompt1&#39;, Prompt) # get the runtime<br>
&gt; api for component named &#39;prompt1&#39; that is an instance of Prompt<br>
&gt;<br>
&gt; Once you have one of these runtime objects you can do a number of things:<br>
&gt;<br>
&gt; * read its attributes (rc.prompt_string)<br>
&gt; * write its attributes<br>
&gt; * setup notifications rc.add_notification(&#39;prompt_string&#39;, callable) #<br>
&gt; callable is called if prompt_string changes.<br>
<br>
</div>I think you could maybe do all of this with properties. Notifications<br>
could be handled with a decorator.<br>
<div class="im"></div></blockquote><div class="im"><br>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.<br>
<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I agree. It would be confusing trying to figure out whether the<br>
desired attribute or method is found on the component itself or on the<br>
rc attr. Maybe I&#39;m just not familiar with any projects that do it this<br>
way, so the is-a paradigm feels more natural.<br>
<font color="#888888"></font></blockquote><div><br>I think this is an IPython thing that we maybe want to get away from.<br><br>Cheers and thanks,<br><br>Brian<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
Darren<br>
</font></blockquote></div><br>