my apologies  for the repost.   I thought there was a technical problem and
did not intent to push for an answer.
If a message is not observed by a poster on the list  unless there is a
first reply, i was unaware of such  policy/config.

On Sat, Apr 21, 2012 at 5:34 AM, Brian G. Peterson <brian@braverock.com>wrote:

> First, please don't repost.  We all got your first message, and someone
> likely would have responded.
>
> On Sat, 2012-04-21 at 02:19 -0400, slava zimine wrote:
> > below is an example which shows a problem when barChart with complex  TA
> >  argument is called from within a function, in this case chartingfoo()
> <...>
> > Rationale:   I wish to make a package  which contains some S4 Objects
>  and
> > i would like to put charting functions inside S4 methods.
>
> Really?  Why use S4.  They're a pain, don't work all that well, and
> interfere with other code dispatch way too easily.  S3 and Reference
> Classes both work better.
>
> When evaluating S3, S4  i've estimated S4 offers more of OO formalism, but
would agree  S4 has its share of problems  and tricks to be used as  a
workarounds.

Thanks for mentioning the Reference Classes.



> > The current workaround   is to  externalize  charting code in separate R
> > files and requiring user to  source them at session start.
>
> If you need to source files into an environment, you may be having
> scoping issues, but these could always be worked around by not creating
> naming collisions, or by scoping them explicitly using get() and
> do.call()
>
> > Any comments will be appreciated.
>
> For you and all the other folks who keep commenting on chartSeries and
> addTA and barChart and so-on, development has moved on to the new
> chart_Series, add_TA, etc.


After  digging more through  some old topics  the currently  found
 workaround with addTA

is to use :

   assign('ta_arg_obj', ta_arg_obj, envir=parent.frame())

and rm(ta_arg_obj, envir=parent.frame() )    after  a call of
chartSeries(xts, TA='addYourCustomIndic(ta_arg_obj)')

from a non base  environment



>  They're faster and the code is much more
> manageable.  Basically no effort is going to be put into the old code by
> anyone with commit access to quantmod and xts. This has been discussed
> on this list before.
>
> What does that mean?  It means that you should also move your energies
> to the new functions.
>
>
Many thanks for pointing out that there is a new version of quantmod  in
development

Slava




> Regards,
>
>     - Brian
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
>
>

	[[alternative HTML version deleted]]

