Re: What to do for bad arguments to foreign-status-plist?
hga@xxxxxx 12 Aug 2020 12:38 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