> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, August 30, 2020 10:35 AM
>
> I think the main source of confusion/disagreement has been this:
>
> - You want status objects to belong to a class hierarchy (like single
> inheritance in OOP).
>
> [ Inserted from followup email: ]
>
> More precisely (if I understood correctly): you want a core set of
> properties to belong to a class hierarchy which gives their meaning.

I don't think so.  Let's take 'sqlstate.  Some databases might be able
to use it as is, have no quirks that demand a sub-convention like
'postgresql (but see below).  Let's look at my example from the
document: https://htmlpreview.github.io/?https://raw.githubusercontent.com/johnwcowan/srfi-198/master/srfi-198.html

'(convention sqlstate
  sub-convention postgresql
  sqlstate "28P01"
  category exception
  class-text "Invalid Authorization Specification"
  condition-name invalid_password
  scheme-procedure open-database-connection
  foreign-interface query-message
  message "open-database-connection: 28P01: incorrect password"
  args ("localhost" 5432 "ecb" "ecb"))

Not a single one of those keys is axiomatically unique to the
'sqlstate convention except of course the at least partly standardized
5 digit 'sqlstate key.

The same is true of every property except 'sqlstate, 'postgresql, and
"28P01" (while it fits into the SQLSTATE system, I believe that
particular state is unique to PostgreSQL), and of course some details
in 'message and 'args.

But the exact meanings of 'category, 'class-text, and 'condition-name
***might be different in another convention***.  ***And they get their
precise meaning from inheritance*** from the 'convention and perhaps
'sub-convention.*

This is almost worth emphasizing in all caps.  In your vision as I
understand it, the issues of naming and meaning are much more stark,
because if 'category for example became one of the 15-50 standard
keys, it could have only one meaning.

I've not yet tried to construct statuses for any other database; on
the other hand, the status needs to have *some* key and property to
tell you this is a PostgreSQL foreign status so you know where to look
up "28P01" without requiring a general search engine, or consulting
the code, or just happening to know PostgreSQL is the database engine.

> Other properties are auxiliary, nice-to-have, and can exist independent
> of the hierarchy.

"It depends...." (Maybe not so relevent given what I've said above.)

> My position is: why can't we have more than one such cluster of
> properties? Maybe you say that we can, but you'd still like one cluster
> to be the main one and others auxiliary, perhaps dividing the main class
> into subclasses (or convention into subconventions / set into subsets).
>
> Maybe we should solve this by sketching examples of real use cases.

I tried to do so in the SRFI text; let's avoid the POSIX errno example
where some properties can have many valid keys, we'd just need to
decide which are which, and go to the simplest, a UNIX(TM) style
'generic-c-lib that to the very limited extent I've exercised it, only
returns 0 on success and -1 on failure, and as I recall you don't get
anything more in any way:

(convention generic-c-lib
 sub-convention libsodium
 scheme-procedure generate-key
 foreign-interface sodium-init
 message "generate-key: ecb-generate-key could not initialize sodium library\n")

Here the sub-convention is just to tell you that it came from
libsodium instead of, say, something interacting with a cloud API, the
other keys are bog standard ones that are also used in the above
PostgreSQL example.

> - I believe a single-inheritance class hierarchy would 1) add complexity
> we don't need;

I believe we need the complexity you fear, and that it also reduces
... if not complexity, intensity needed to define the "standard" keys
without painting ourselves into a corner when for example a new
foreign interface uses a word or words of art that are already one of
the existing 15-50 standard keys.

> 2) risk painting us into a corner if we get statuses that
> have a "multiple personality" and we have to arbitrarily decide that one
> of the personalities dominates over the others.

The real world is messy, not sure the cost of the above dilemma is
greater than the cost of my vision.

> It also seems to me that your main opposition to my approach is that you
> think it's 1) confusing to the user receiving status objects; 2)
> unreliable to the user receiving status objects.

My main objections are WRT to the user creating status objects, but as
illustrated above, the consumer of them is of course also in play.  If
a convention tightly defines what a key's property means, 1) should not
be an issue aside from looking that data up in the library documentation
or the Schemeregistry, 2) I don't understand your question.

> Is this reasonable close?

Nope.

- Harold