Re: [GT] patches for GT/Systems.pm and GT/Systems/Generic.pm

["Robert A. Schmied" <ras AT acm.org>]

Weigert, Thomas wrote:
> I don't understand the patch to Systems.pm. What reason do you have to
> think that '' is a good parameter for key? Nowhere else is '' being
> passed as a parameter to $key. 

i have to take exception to this last statement. there are plenty of places $key is
being set to either "" or ''. here is a very truncated list:
GT/Signals/Trend/HilbertChannelBreakout.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");
GT/Systems/Swing/Trend.pm:    return manage_object(\
AT
NAMES, $self, $class, [ ], "");
GT/Systems/Stochastic.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");
GT/Systems/TTS.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");
GT/Systems/AlwaysInTheMarket.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");
GT/Systems/TFS.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");
GT/Systems/MacdDiff.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");
GT/Systems/SMA.pm:    return manage_object(\
AT
NAMES, $self, $class, $self->{'args'}, "");


                                Please explain. Th.
>


investigating this in some detail i've found:
 i) the 'real' manage_object method is in GT/Registry.pm. all the
    other references of it are perl prototypes?
ii) manage_object passes $key (undef if not passed as an input param) to
    build_object_name (GT/Registry.pm) which appends the string "($key)"
    including the parens, excluding the quotes, if $key is not undef, 0 (zero)
    or the empty string ("" or '') to the name being constructed.
 -- so passing "" or '' as a $key to manage_object shouldn't concatenate
    '()', without the quotes to the name being created by build_object_name.
 -- but conversely, there shouldn't be a need to set the 'optional' parameter(s)
    to anything either, unless there's something funky happening as a result of
    the perl manage_object prototype or something else that i've missed.
iii) including the referenced patch in this message thread, many calls
    to manage_object set the 5th argument ($key) to "" or '' or to an actual value.
iv) an indicators' inherited new method (from Indicators.pm) will accept, but
    cause a runtime error if a 6th argument ($func) is supplied. most, but not
    all indicators inherit the new method.
 v) an analyzers' inherited new method will accept and pass a 6th argument ($func)
    to manage_object. it seems all analyzers inherit the new method.
 -- manage_object only expects 5 parameters (well six if you include its'
    $self thing $repo)?
 -- could getting 6 but dealing with only 5 arguments cause any sort of runtime issues?
    (i'm thinking no, the extra one is just silently ignored).
vi) focusing on GT/Systems.pm new method: the pod suggests and all the
    existing system modules implicitly agree (because they all, save Generic
    which inherits new from GT/Systems.pm, set the $key arg to ""), that
    the $key parameter isn't a supported option for a system.
vii) the new method provided by GT/Systems/Swing/Trend.pm sets the 4th parameter,
    normally the hash '$self->{'args'}', to an empty array? '[ ]'.
        GT/Systems/Swing/Trend.pm:    return manage_object(\
AT
NAMES, $self, $class, [ ], "");
    i don't know what the effect/intent/purpose of that (completely uninvestigated),
    but it is a one-of case.


i'm not sure what to do next about this inquiry.

the only outstanding thing i see is that the new method in GT/Systems.pm is inconsistent
with the new method provided by all GT/Systems/*.pm except for GT/Systems/Generic.pm which
inherits it. the inconsistency is whether or not new accepts a $key parameter as an input.
excluding the new method from GT/Systems.pm, calls to manage_object set the 5th param
($key position) to the empty string. in no case does a pre-defined system attempt to set $key.

it's conceivable that a generic might attempt it -- is that the essence of this inquiry?
if so, where does the value used for $key come from when a generic system is being created?

i think the design is such that a system would never need to disambiguate a name via the
$key string extension.


ras