RE: [GT] SVN Commit r623 - trunk/GT - object alias resolution

["Weigert, Thomas" <weigert AT mst.edu>]

RAS,

While I disagree with each of of your points, for the sake of moving on
I shall
- move the loading of object alias into the resolve_object_alias routine
- implement the "load once" solution based on semaphores

I really think the default path /usr/share/geniustrader is a very bad
idea. Having hard wired paths is already a bad idea, but having
hard-wired paths that are not guaranteed to exist is an even worse idea.
Not every user has control over their system; often such users are
prevented from creating directories in /usr or /usr/share (if that
exists). In particular, the common directory is probably used primarily
where more users share a GT installation and in these scenarios it is
more likely that access to /usr is controlled.

Th.

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Wednesday, May 14, 2008 2:18 PM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] SVN Commit r623 - trunk/GT - object alias resolution
> 
> 
> my objections to the changes made via this change notice are
basically:
> 
>   i) the change to GT::Conf::load materially alters the methods
>      operational effects while not ensuring it solves the problem.
> 
>  ii) preventing multiple object alias loading can be achieved without
>      making changes to any other method.
> 
>      in addition, one can argue that moving the object alias loading
>      code to GT::Conf::load doesn't guarantee multiple loading
>      won't happen. should some script call GT::Conf::load a second
>      time to load a file other than the default $HOME/.gt/options file
>      the object alias loading code will be executed again.
> 
> iii) the change related to 'the disliked' path is just change
>      for change sake as far as i can tell. the path need not exist,
>      ever, the code does not care and operates without issuing
>      complaints or warnings should the path not exist.
> 
>      this path is a reasonable, practical default (at least for
>      *nix platforms), and users can easily change it if it isn't
>      suitable for their environment.
> 
>      changing the path will adversely affect anyone using it.
> 
>      not providing hardwired default values requires additional code
>      that handles (ignores) uninitialized variables.
> 
>      forcing all users to update their $HOME/.gt/options file in
>      support of a no-change change isn't reasonable.
> 
>  iv) regardless of how small the impact is, there is nothing to be
>      gained by always loading (or attempting to load) data that is
>      unneeded.
> 
> 
> ras
>