On Tue, 16 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Tue, 16 Oct 2018, Sven Schreiber wrote:
> Am 16.10.2018 um 16:03 schrieb Allin Cottrell:
>> On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
>>> Dear Allin,
>>> This is the way I was afraid of the most.
>>> Is it possible to have some substitute?
>>> Say, getvalues(int ID) similar to getinfo()?
>> My first thought for fixing this (now in git) was to limit access to
>> series IDs within functions: the function gets to "see" only the IDs of
>> series that were passed via a series-pointer argument or as members of a
>> list argument.
> I think this was the correct fix, because the other trick was against the
>> Now Oleh implies that this change will break some of his functions. I'm
>> willing to consider an alternative fix but I think we need to be clear on
>> the rationale for allowing access to series not given to a function via
>> arguments. (I take it that is what Oleh wants.)
> I agree, in the sense that I think such a rationale must be very strong if
> the important principle of function encapsulation were to be weakened.
I agree with Sven 100%.
The policy of function encapsulation must be kept at all costs (ok, with the
obvious exception of "const" and "time", that are generated on the
(actually, the same would hold for seasonal dummies as well, but we doi have
the seasonals() function for that).
If enforcing the principle with consistency breaks a package, I'm sorry, but
it's the lesser of two evils. A package can always be updated with little
I agree too, but we'll need a transitional period.
Here's one reason why (perhaps it's the only reason). My recent
restriction on access to series within functions was too restrictive
in that it did not give access to series that are members of a list
passed as a bundle-member (as Oleh pointed out).
Now I'm not 100% sure what is "right" in that context but it's clear
that (a) we can't just close down such access (that would break 14
function packages) and (b) it won't be a trivial matter to get the
handling of bundle-member lists sorted out properly. So I think I have
to back off on the new restriction until the bundle-member case is
fully worked out and well tested.
Fortunately, I've seen a way to avoid the worst fall-out from
"penetration" in the meantime. As I pointed out in
the real trouble occurs when series that belong in main get stuck with
a "stack level" > 0 when function-execution terminates. So here's a
suitable hack: whenever we exit back to main, run a little loop that
puts all series back to level 0.
The point is that any "surviving" series (i.e., not local to any
function, and therefore destroyed on exit) that have level > 0 can
only have got into that state via the mess-up Oleh identified; they
must really belong in main.