IoC Speculations

[Antranig Basman]

Thanks for this review, Colin. Answers to questions at base:

Colin Clark wrote:
> 
> Hey,
> 
> On 1-Jun-09, at 9:30 AM, antranig at caret.cam.ac.uk wrote:
> 
> > I have created a small page where I have written up some of our recent
> > discussions on the need/mechanism for IoC within our framework -
> >
> > http://wiki.fluidproject.org/display/fluid/IoC+Speculations
> 
> This looks really good. A slightly goofy but highly informative
> document. ;)
> 
> Here's my attempt to summarize it for those who haven't had a chance
> to take an in-depth look:
[]

> A couple of questions/comments for you, Antranig:
> 
>   * Do we need to qualify properties with "that," or can it simply be
> assumed? Where else could a subcomponent pull dependencies from,
> except from its parent? So for example, your code here:
> 
> fluid.demands("fluid.pager", "fluid.pager.renderedPageList",
>         ["that.container", "that.events", "that.pagerBar.options",
> fluid.COMPONENT_OPTIONS, "that.options.strings");

Yes, my idea for qualification was to be able to refer not only
specifically to the "immediate that", that is, the "that" of the
component which is most immediately executing initSubcomponents,
but also any "outer nested thats" - that is, any others in whose
initSubcomponents this instantiation may be nested. This is what
is proposed about 3/4 of the way down with syntax perhaps like
"that{fluid.pagerBar}.options".
I also imagined that any string not beginning with "that" would
simply be resolved as a global EL path, for example to some 
constants that were sitting in the fluid.* space or some others.

 
>   * As far as naming goes, my vote is to call the dependency registrar
> fluid.dependencies() or fluid.wiring()

How about fluid.depends()?

>   * As it stands now, components need to specifically support
> decorators, and the signature for all decorators is fixed. This
> approach seems to provide us with a totally general system for
> component decorators. Is that right?

Yes, the system of specialised "decorators" I imagine would largely
go away.... although there seems no particular reason to deprecate
the old system, other than clarity. Since "subcomponents" are just
functions, it should make no difference to the subcomponent which
system (if any) it is participating in - this is an "invoker-only"
change. Although I imagine for more dedicated subcomponents we
would end up simplifying their arguments list as a result of 
having this facility.

> Colin
> 
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org