[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [GT] key and func
Note that in the previous version the key and func arguments were of course heavily used, but we finally have eliminated these from all indicators.
Looking at the previous usage, I cannot see what one would, under normal circumstances, use these now for. Just as a reminder, in the previous system, the usage was as follows:
1. set up $self->{'func'} to get the desired data stream, e.g.,
$self->{'_func'} = $GET_LAST;
would get the close of the current price ($GET_LAST is a function retrieving the close of the current prices array).
2. Obtain the current value via the function pointer:
&$self->{'func'}($calc, $n)
Of course, this can be accomplished much easier with using the I:Prices indicator. In fact, any data series that is stored in the data directory in a normal file can be obtained in that manner.
So really, only if one wanted to obtain a data series from somewhere else, e.g., a file stored in a different location, or data pulled over from a socket or the web, would one need to resort to the func argument.
With respect to the key argument, I have not been able to locate any usage at all, even in the older code (but I may have missed that).
So the question is: Is there a need to support the access to data that is not stored in a market file in the data directory? If we want to do so, we should document some example, and we also should clarify how key is used in all that. Otherwise, there is some dead code that can be removed and make the system clearer.
Please advise, Th.
> -----Original Message-----
> From: Weigert, Thomas
> Sent: Monday, March 17, 2008 4:39 PM
> To: 'devel
AT
geniustrader.org'
> Cc: Weigert, Thomas
> Subject: key and func
>
> Raphael,
>
> Thanks for chiming in. Maybe you could add some more clarification here,
> as from looking at the code, the $key and $func stuff seems to be just
> dead code:
>
> Passing key and func values is relevant here:
>
> 1. GT::Registry::manage_object
>
> a. Store $key in $obj->{'key'}
> b. Add "($key)" to the name of each of the return series
>
> 2. GT::Indicators::new
>
> a. Store $func (or a default function) in $self->{'func'}
>
> 3. GT::Analyzers::new
>
> a. Store $func (but not a default function) in $self->{'func'}
>
> There is no single place where either key or func are used.
>
> In summary:
>
> All module creation routines add representing a key if passed in new.
> Only Indicators and Analyzers store a function pointer (with or without
> default)
> These are not used.
>
> Could you provide an example of how one would leverage these two entities?
> It appears to me that this is dead code at this point and should just be
> removed...
>
> Please advise.
>
> Th.
>
>
> > -----Original Message-----
> > From: Raphael Hertzog [mailto:raphael
AT
geniustrader.org]
> > Sent: Monday, March 17, 2008 3:27 AM
> > To: devel
AT
geniustrader.org
> > Subject: Re: [GT] patches for GT/Systems.pm and GT/Systems/Generic.pm
> >
> > On Fri, 14 Mar 2008, Robert A. Schmied wrote:
> > > and the similar statement from GT::Signals::Module->new
> > >
> > > "Create a new signal with the given arguments. $args and $key are
> > optional,
> > > they are useful for signals which use non-usual input streams."
> >
> > IIRC $key is a unique string identifier for the "non-usual input stream"
> > and the "non-usual input stream" is represented by the function pointer
> > $func used to retrieve data from that stream.
> >
> > Cheers,
> > --
> > Raphaël Hertzog