[DGD] FLS

[bart at wotf.org]

On Tue, 10 Oct 2017 11:47:12 -0700, Raymond Jennings wrote
> I said that already :P

I must have missed that in the longish thread.

> 
> Two geeks agreeing on the idea though is probably a good sign :)

No no, the sky must be falling!

Bart

> 
> On Tue, Oct 10, 2017 at 11:48 AM,  <bart at wotf.org> wrote:
> > You probably could achieve that from lpc by overriding call_other().
> >
> > Bart
> >
> > On Wed, 4 Oct 2017 17:45:38 -0500, Blain wrote
> >> 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
> >> >
> >> >
> >> ____________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> > --
> > http://www.flickr.com/photos/mrobjective/
> > http://www.om-d.org/
> >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


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