[Nitro] Simpler configuration method?

transfire at gmail.com transfire at gmail.com
Sun Feb 4 10:43:51 EST 2007

On Feb 4, 10:04 am, Malte Milatz <m... at gmx-topmail.de> wrote:
> I'm looking at the first message of this thread, trying to understand
> what is being discussed. Please don't take this as a rant, I'm really
> trying to understand your views, by asking questions:
> George Moschovitis:
> > The main drawback of the current version is that you have to
> > define the classes to be configured before executing any configuration
> > code and/or require the glue/configuration.rb file. This prohibits
> > the reusability and flexibility of the configuration files.
> I don't really get the point you're making here. What reusability? If I
> set some attribute, I always know what attribute I'm going to set on
> what object. Why would I want to use a library without loading the
> library? Why would I want to configure something I do not use?
> > Moreover, as the configuration system uses annotations there is a
> > slight performance penalty that may be serious if a configuration
> > variable is used in a tight loop.
> Actually, this Annotation thing strikes me as a programmer as a little
> odd. A server's root directory is an attribute of this server, thus it
> is natural to do something like
>         server = Framework::Server.new
>         server.root_dir = my_dir
> Opposed to that, it is not the job of a class (here: Server) to care
> about the root directory of my specific server. If I do not instantiate
> the server myself, i.e., the framework has done this for me, then the
> lines above would read something like
>         server = application.server
>         server.root_dir = my_dir
> or
>         application.server.root_dir = my_dir
> but never
>         Framework::Server.root_dir = my_dir
> At least that's my understanding of OOP design.
> Now, who is going to enlighten me? :-)

I agree! What's being done presently is using a class/module as a
global variable store. This is good case of how Ruby can somtimes be
too flexible for it's own good. If you want globals then use a global
var. eg.

  $nitro.server.root_dir = my_dir

But I still think this probaly could be done better (albiet with a
little more work) w/o globals via IOC.


More information about the Nitro-general mailing list