key value type hierarchy and meta data use

[mhaberler]

Interpreting config items as a particular value type is a common use case - basic types like int, unsiged, float, string, bool etc to start with

How are type hints communicated to using code, if at all? if so, I would assume standard metadata keys could be used to provide such hints, and be used to type-convert such values already within the library

Is there such a metadata taxonomy for basic types ? It looks like 'meta data' is intended more as a comment feature.

it seems to me external specifications are the suggested way to address this.

Do 'specifications' make their way into metadata? if not: this kills any runtime type introspection capability - sharing config information outside a config information transport vehicle is a bit of a non-starter.

Is there any strong reason not to eat one's own dogfood with type information?

[mhaberler]

NB: specificationis a 404 on https://github.com/ElektraInitiative/libelektra/tree/master/src/tools/gen

[markus2330]

(Thanks for report, links are fixed.)

Metadata is not only for commenting, but also to formally specify the content of the key. See the current specification for metadata. Many of these, e.g. binary, check/type, check/validation are enforced by API and plugins.

For check/types currently only CORBA types are in use, but I plan to improve on that during summer. Also that the specifications can be mounted (in spec namespace and then make their way to metadata) with automatically run-time enforcement is part of that.

Only with code generation structural static type checks can be done and this is implemented (see your posted link above). What exactly do you miss? A primitive C API like keyGetInt()?

[mhaberler]

what I thought of was: access a value through the base API and either have it converted to the type associated with the key, or in the minimum retrieve the intended type for that key

that enables ad-hoc introspection

by ad-hoc I mean: the only shared state should be the namespace and nothing else - that is - no further out-of-band shared information like specifications which - in case they propagate to clients as setup-specific code - are a major management problem

[markus2330]

Metadata can be appended directly to keys, that was the only way when no spec namespace existed and of course still will be supported.

Regarding the ad-hoc introspection: Do you think about languages like python or also C?

[mhaberler]

well latent typing languages profit most of type introspection, but certainly at the C level it would be reassuring to know the intended type if only for basic protection/logging of configuration errors

if I need a numeric type of some sort and the intended type is say string or blob, that certainly would be a setup error in the key's type. What do you do without type information?

[markus2330]

Without any type information it could be anything.

The code generator makes sure that the application does not intend to use a type incorrect. Together with run-time checks in the plugins all situations are covered.

Can you give me a concrete example what you want to do with introspection? (Next to ad-hoc development)

[mhaberler]

we might be talking past each other. I am talking about something rather simple.

I want to find out if it is possible to associate a type with a key, and retrieve that type ID with the normal C API. To mean: the type is associated with, and will be retrieved with the key in-band.

No code generator no nothing, and no-out-of-band type information through specifications. in-band, In-tree: possible or not?

Example: Assume qt-gui could introspect types of keys - in which case it could verify keys on entry

[markus2330]

Michael Haberler wrote:

we might be talking past each other. I am talking about something rather simple.

We might still do, can you give a pseudo code for what you try to achive?

I want to find out if it is possible to associate a type with a key, and retrieve that type ID with the normal C API. To mean: the type is associated with, and will be retrieved with the key in-band.

Even the specification is retrieved using the very same kdbGet(), so it also could be considered "in-band".

Metadata, however, can be attached to any key, not only spec keys. So you can add type information to e.g. system and user keys, too. The underlying configuration format must be able to cope with it, e.g. json/yajl will give you double and boolean next to strings.

No code generator no nothing, and no-out-of-band type information through specifications. in-band, In-tree: possible or not?

Yes, definitely possible. Metadata is a fundamental part of every Key.

Example: Assume qt-gui could introspect types of keys - in which case it could verify keys on entry

Yes, it could. At the moment it only displays the type information. Enforcement of type information is done by plugins. Validators directly in the GUI using the type-information are still worthwhile for a better usability, but are not implemented yet.

[markus2330]

The question should be answered: It is easily possible to transfer type-information in-band (within a Key). It is planned that the web-ui validates values using this information.