What to do for bad arguments to foreign-status-plist?
hga@xxxxxx
(10 Aug 2020 15:10 UTC)
|
Re: What to do for bad arguments to foreign-status-plist?
Lassi Kortela
(10 Aug 2020 15:14 UTC)
|
Re: What to do for bad arguments to foreign-status-plist?
hga@xxxxxx
(10 Aug 2020 15:29 UTC)
|
Re: What to do for bad arguments to foreign-status-plist?
Lassi Kortela
(10 Aug 2020 15:38 UTC)
|
Re: What to do for bad arguments to foreign-status-plist? hga@xxxxxx (12 Aug 2020 12:39 UTC)
|
Re: What to do for bad arguments to foreign-status-plist?
John Cowan
(12 Aug 2020 12:59 UTC)
|
Re: What to do for bad arguments to foreign-status-plist?
Lassi Kortela
(14 Aug 2020 13:31 UTC)
|
Promise objects
Lassi Kortela
(14 Aug 2020 13:46 UTC)
|
Re: Promise objects
Lassi Kortela
(14 Aug 2020 14:04 UTC)
|
> From: Lassi Kortela <xxxxxx@lassi.io> > Date: Monday, August 10, 2020 10:38 AM > > [...] > >>> What does `foreign-status-plist` do, return the whole plist? >> >> Yes. Except it may generate a new plist because (2nd item below): > > Good. > >>> Does enumerating the properties need to be in the API? >> >> My theory is no, because plists are so simple, although it would be >> nice to have a plist SRFI, even as a placeholder, to direct people to >> for simple utilities like that. The foreign-status-properties you >> suggest below would just duplicate one of its procedures. > > It doesn't just duplicate a generic plist procedure, it maintains > encapsulation. That's a good argument. It could be addressed by for example changing foreign-status-plist to foreign-status-keys, providing a list of all the keys in the status object. I've made this change to the SRFI. > Our keys are dumb objects - just symbols. Values may be smart > (transparent lambdas), as may the container type (can use something else > instead of plist). A procedure that enumerates just the dumb parts more > easily handles the abstraction as it evolves. > > A `foreign-status-plist` will have to fetch values for all keys, even > such keys that are not of interest to the caller. If we add transparent > lambdas, then *all* of them will be called in a non-deterministic order > whenever the user does `foreign-status-plist`. > > Forcing the user to explicitly call `foreign-status-ref` as the sole > value accessor makes it explicit to the user when they are resolving a > property value. More good arguments, and this makes it cleaner to defer the decisions about transparent lambda calling to the next draft. > >> and we can postpone the decision about transparent lambdas. > > > > Right now transparent lambdas are off the table, and I assume won't be > > put back on it unless and until we nail down localization, and then > > look at it and say, hey, this bit right here should be magical like that. > > Please at least consider my points above. It's not good to pin things > down too early. Well, we went back and forth, and I think now back on this. It's now one of the Issues. I want a concrete example of their utility, this might be addressed as we add localization. - Harold