[DGD] FLS

[Blain]

I implemented the this_user idea in the kernellib's TLS implementation, but
there was no easy way to tell if the setting corresponding to a given frame
is expired.  So thus the FLS idea was born.

If DGD could supply a null element before the first arg, all else could be
handled by the lib.  The current klib's implementation of TLS could also be
made to use this instead of having to create wrappers for entry-level
functions in driver.c to basically do the same thing (except with only
frame 0).

On Oct 4, 2017 17:01, "Blain" <blain20 at gmail.com> wrote:

> I envisioned looping backward to find the latest setting for implementing
> something like this_player(). Obviously not all uses of something like this
> would need to do that, though.  Another possible use is to let a frame
> store unique data that later frames can query, such as stack-based security.
>
> On Oct 4, 2017 16:10, "Felix A. Croes" <felix at dworkin.nl> wrote:
>
>> Blain <blain20 at gmail.com> wrote:
>>
>> > I'm talking about one for each frame so that it goes away automatically
>> > when that frame goes away.  An example use is a variable for the current
>> > user/player/body in a given frame that is automatically rolled back when
>> > the frame ends and focus goes back to a previous frame, who's current
>> > user/player/body variable will then be on top.
>>
>> This is more than what you called FLS, since it also involves setting a
>> new value for each frame, or else falling back to a value provided by a
>> previous frame.  I would describe that as stack-based, rather than
>> frame-based.
>>
>> If you're looking for a this_player() equivalent, there is an example
>> implementation in the LP 2.4.5 mudlib simulation.  It doesn't use, but
>> could be done with, thread-local storage.
>>
>> Regards,
>> Felix Croes
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>
>