[DGD] FLS

[Raymond Jennings]

This might be relevant, to why DGD prefers not to give you silver
bullets, but rather the raw ingots you need to forge your own.

Examples:

Instead of arbitrary limits on stack and ticks, giving an rlimits so
that the programmer can enforce limits of his own choosing, and that
includes letting the driver object audit all rlimits calls at runtime.

Instead of a full blown SSH implementation, DGD implements the ASN
functions as building blocks, and lets a higher LPC layer actually
hook the pieces together.

Instead of this_player and so on, you get infrastructure to track it
yourself if you want to.

The philosophy seems to be to give you the parts and let you use LPC
to hook them together how you like.

This is a philosophy I agree with.  Policy stuff and logic things
belong in LPC anyway.

On Fri, Oct 13, 2017 at 5:18 AM,  <bart at wotf.org> wrote:
> 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd