RE: [GT] SVN Commit r623 - trunk/GT

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

Lets keep in mind what the original situation was:

Whenever an object alias is required, the following files were loaded:

'/usr/share/geniustrader/aliases/signals'
'/usr/share/geniustrader/aliases/indicators'
'/usr/share/geniustrader/aliases/systems'
'/usr/share/geniustrader/aliases/closestrategy'
'/usr/share/geniustrader/aliases/moneymanagement'
'/usr/share/geniustrader/aliases/tradefilters'
'/usr/share/geniustrader/aliases/orderfactory'
'/usr/share/geniustrader/aliases/analyzers'

This is bad for the following reasons:

1. The user has no control where these directories were. If one wanted
to use object aliases that are shared, one had to create these
directories. A user may not be allowed to create subdirectories in
/usr/share

2. These files are loaded every time an object alias is resolved, albeit
their content is needed only once.


You are correct in that loading these (if defined) in the loading of
options did not happen before, but

1. now it is well controlled and can also be prevented
2. the directories can be chosen to a users liking.

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Wednesday, May 07, 2008 4:43 PM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] SVN Commit r623 - trunk/GT
> 
> 
> taking this a bit further, if an app (script) were to be developed
that
> expressly wanted to load a file other than $HOME/.gt/options from
> someplace
> other than $HOME/.gt, by extension i'd expect it might want to get
> alias
> files from that other someplace as well. this change doesn't support
> that
> altered directory path.

Well, I might be misunderstanding you, but if a user would load from
other than the $HOME/.gt location, whatever file is loaded can define
Path::Aliases::<object kind> differently and thus cater to your
requirement.


> 
> even though it requires another method, say load_object_aliases() and
> a call to it added (some how) in every script (application) i think
> that would be the preferred solution.

Don't see the point of adding more burden for the user.

I must be misunderstanding your need above. Can you please outline the
requirements?

Note that in the previous scheme, none of what you are talking about
here would be possible.

> 
> 
> an alternative, one that doesn't support an alternate directory (other
> than the default GT::Conf::_get_home_path()."/.gt/aliases/", would be
> a semaphore on GT::Tools::resolve_object_alias that inhibits multiple
> loads. i think what would be simpler and have the same intent.

Yes, but what would the point be?

> 
> ps -- GT::Tools::resolve_object_alias (isn't) wasn't called in the
> unchanged version unless an object alias is detected via the "@"
> marker.
> the "@" marker proposed removal would require
> GT::Tools::resolve_object_alias
> to be called for every call to create_standard_object.

You are correct. There would be an additional call in each case. This is
not a big overhead, as those objects are not created in a tight loop.

I actually don't care one way or the other. You raised the question
about what object aliases were, and I went to look into the detail and
found this inconsistency.

System aliases are called just like normal names, object aliases require
"@". If users are not bothered by that, no need to change.


> 
> also note that GT::ArgsTree::parse_args (at least the ones i've got)
> resolve object aliases using the "@" marker as well, that wasn't
> changed
> in the proposed object_alias.patch
> 

You are correct. Thanks.

As said earlier, I am fine with leaving things as is... I am not using
object aliases...