[DGD] FLS

[bart at wotf.org]

On Tue, 10 Oct 2017 17:55:52 -0500, Blain wrote
> I'd love to see examples of mimicking this behavior with existing
> capability.
> 
> A stack held in the TLS won't step back with the call stack when a given
> frame is deleted.  Old data would persist and become confusing.
> 
> Not every frame is invoked with call-other.  Even if they were, using
> call_other would require a variable be manually added to every 
> function in the library.

The first item is correct, this would only work for 'inter object' calls.

The second however isn't correct, you'd solve that in exactly the same way as
the tls is created, ie, call_other() calls a second function, lets say
_call_other() which accepts the array/mapping for the FLS, and then that
second function calls the actual function with its original arguments.

> 
> This idea is not only useful to a this_user/body style stack.  It 
> could be used in other non-gamr implementations as well.  It's 
> simply frame-based volatile data dump.  Temporary redirections of 
> output, i.e. piping, might be done here, for example.

To me, local variables are already that, a frame based volatile data dump, but
with the difference of them not being available to a called function unless
passed explicitly. This makes them useless for certain things, but also
prevents 'magic' behavior. Explicit code to wrap something which uses
redirected output, while a bit more code, is explicit and clear, and can
prevent such 'magic' behavior.

Yes that is a little bit more work because you have to write a bit more code,
but it is explicit, and does not result in 'where is my output going now',
'why am I not seeing what I expected' and such situations without there being
an explicit point in the code causing those which can be found relatively
easily. I certainly haven't seen everything, but every example I have seen of
the use of FLD can be done without FLD with a slightly different design and a
bit more initial work.

Note that having to write more code, but ending up with code which more
explicitly describes what is happening, is something you are going to thank
yourself for when looking at that code again a few years from now. Unless you
write code for things which will be run a few times at most, the time you
spend on writing the code is typically dwarfed by the time spent on
maintaining that code and hence reducing the later should be a much more
important consideration than reducing the first in many cases.

> 
> How much overhead would something like this add? If a given implementation
> did not utilize it, what kind of unnecessary burden would it impose? 
>  Could a compile-time toggle flag be useful here?
> 
> I think if it did exist already, many people would already be using it.

I'd avoid it myself for above mentioned reasons. Yes, it makes it easier to
write certain things, but the price is 'magic behavior'.

Sorry but this needs a bit of a rant...

Decades of having sideline involvement with software development shows some
things never change. Developers are prone to chase silver bullets: new
paradigms that will solve every development issues supposedly. Additionally
developers are always much more interested in making new things as opposed to
maintaining existing things. 

Those 2 things combined result in the same mistakes being repeated over and over:
- focus on initial development time, with little regard for possible
maintenance time.
- a new paradigm every couple months results in inconsistent code which
requires switching between various paradigms depending on which part of a
codebase you are looking at, or a need to refactor the codebase over and over
and over (etc)
- going 'all the way' whenever a new paradigm arrives, trying to write
everything using that one new magic approach. Sorry but that is like saying
'one size fits all' and then constantly changing that one size that should fit
all. Certainly new approaches tend to have their value, but only when used
appropriately, ie to address the actual problem for which they were conceived.

Or put very differently: if you want to create new things which aren't going
to be irrelevant within an extremely short time, chasing the next fashionable
development approach is a sure way to not get where you want, because it will
be eating too much of your time.

Bart
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/