On Sunday 05 September 2004 02:54, Jamis Buck wrote:
> Simon Strandgaard wrote:
[snip]
> Basically, look at the subsystems (and the sub-subsystems, and so
> forth). You might have a VFS subsystem, a command subsystem, a rendering
> subsystem, and so forth. The VFS subsystem might be further broken down
> into a zip abstraction, an FTP abstraction, and an abstraction for a
> conventional file system.
>
> Once you have an idea of what all the pieces are (and how they relate to
> each other--that's important!) you then arbitrarily change their name
> from "subsystem" to "service", and you're halfway to Copland. The

ah.. changing subsystem to service.. it begins to making sense to me.
The FreeRIDE project uses something similar, with services that can be loaded, 
started, stopped, etc. I think thier IoC is named FreeBase?

[snip long]
> Notice, too, that your services are just plain-old Ruby objects, but
> where they used to instantiate their dependencies themselves, now they
> have setters for those dependencies, and expect to be given them at
> creation time. This has benefits for unit testing, too, since you can
> easily assign mock objects to any property of a service!

I use lots of mocks in my testcode.. 


> Is this a new idea? No. Are you already doing something like this?
> Probably. It's just good design, to minimize coupling between
> components. All an IoC container does is generalize that into a reusable
> framework that you can take advantage of repeatedly and consistently.

Im not doing so at the moment..  instead im using template method pattern.
The class in the 'main.rb' file is derived from the CommandLine class.. main 
just fills in the glue code.. so that I can unittest the CommandLine class on 
its own.

I now see places where IoC could be useful.. require 'fox'  which loads fox 
toolkit and in case it isn't present on the users machine.. then it outputs a 
nice message..  This could be encapsulated as a service.

If I extended my editor with a ruby-debugger then this would be good to have 
encapsulated as a service.


I want subsystems to be defined in the configuration file.. so that things 
which doesn't belong in the editor doesn't bloat it. Maybe copland is the 
solution to setting up services in these configuration files?


> Admittedly, most IoC containers give you more than just "dependency
> injection" (which is more or less what I just described). Copland, for
> instance, provides some AOP-like functionality via "interceptors", which
> allow you to add code that is executed before and after (and around)
> method invocations on designated services. But the dependency injection
> (DI) pattern is the strong point of IoC containers.

That can be useful for debugging.

FreeBASE has a logging system.. where each service can have their own log.
Do you provide similar feature?


> > Martin Fowlers document about what IoC is.. is too long..   I learn stuff
> > by looking at lots of examples. The 3 links you have on your page that
> > should explain its concept.. I don't understand them at all.. sorry.
>
> Well, I hope the above wasn't too long. :) I agree, though--I haven't
> ready completely through Fowler's article, either, though I've skimmed
> most of it. I encountered it after I had a general idea of what IoC was
> all about, though.

Ok.. I think I have gotten an idea about copland.


> I'll work on getting some more comprehensive examples out.

Great


> > Copland looks interesting to me.
>
> That alone is a promising statement. Now if I can just get you to
> _adopt_ it... ;)

At the moment im busy with my studies and kind of lacks time..  I think I will 
do some experiments with for my configuration system with copland. But I 
cannot promise that I will use copland, nor when I will do these experiments.

--
Simon Strandgaard