New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Compatibility: make elektraArrayValidateName public #1735

Closed
e1528532 opened this Issue Dec 14, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@e1528532
Contributor

e1528532 commented Dec 14, 2017

For my type system i came to the requirement that i need to detect whether a key is an array key or not. As this functionality already seems to be provided by kdbease as int elektraArrayValidateName (const Key * key), but marked as internal and thus not in the header.

I'd make this function public instead so i can add bindings for it and use it in haskell instead of reimplementing this myself. Or is there an easier reliable way of determining whether a given key corresponds to the array syntax?

@e1528532 e1528532 added the proposal label Dec 14, 2017

@markus2330

This comment has been minimized.

Show comment
Hide comment
@markus2330

markus2330 Dec 14, 2017

Contributor

Yes, we could make elektraArrayValidateName public within kdbease. (Also for the upcoming release because we have an API change within libease anyway). We should consider renaming it, though. What about elektraIsArrayElement?

But the function might not quite fit of what you semantically want. Can you reformulate what exactly you want to know? Are you really interested in if a key has the syntax of an array element or do you rather to know from the parent if all its siblings are array keys?

If you are interested in the latter question #182 contains a proposal.

Also of interest is a formalization of nested arrays. It is currently not even documented 😞

Contributor

markus2330 commented Dec 14, 2017

Yes, we could make elektraArrayValidateName public within kdbease. (Also for the upcoming release because we have an API change within libease anyway). We should consider renaming it, though. What about elektraIsArrayElement?

But the function might not quite fit of what you semantically want. Can you reformulate what exactly you want to know? Are you really interested in if a key has the syntax of an array element or do you rather to know from the parent if all its siblings are array keys?

If you are interested in the latter question #182 contains a proposal.

Also of interest is a formalization of nested arrays. It is currently not even documented 😞

@e1528532

This comment has been minimized.

Show comment
Hide comment
@e1528532

e1528532 Dec 14, 2017

Contributor

In my case it is really detecting whether a given key is an array key. The reason is, for instance the override metakey is an array, but the underlying function in the sense of the type system (you will see that in the prototype) is obviously only created once, so whenever i encounter such an array metakey like override/#1 = <some other key> i know i can strip the basename #1 and then check for the existence of an override type function.

I have no issue with renaming, though i think validateName is not too bad. It is not actually a boolean check like IsArrayElement would imply to me. Currently it differentiates between 3 possible cases, maybe more in the future. I only need the third case for now (1 meaning its an array element). Therefore we should either leave the name like it is or find another better one, i don't really have any good idea right now.

Contributor

e1528532 commented Dec 14, 2017

In my case it is really detecting whether a given key is an array key. The reason is, for instance the override metakey is an array, but the underlying function in the sense of the type system (you will see that in the prototype) is obviously only created once, so whenever i encounter such an array metakey like override/#1 = <some other key> i know i can strip the basename #1 and then check for the existence of an override type function.

I have no issue with renaming, though i think validateName is not too bad. It is not actually a boolean check like IsArrayElement would imply to me. Currently it differentiates between 3 possible cases, maybe more in the future. I only need the third case for now (1 meaning its an array element). Therefore we should either leave the name like it is or find another better one, i don't really have any good idea right now.

@markus2330

This comment has been minimized.

Show comment
Hide comment
@markus2330

markus2330 Dec 14, 2017

Contributor

Okay, if you are happy with its semantics and its name you can make it public as-is within libease. See doc/todo/API for what to consider (next to have the declaration in the header file).

For the binding: ideally you have two separated bindings (one for core, the other for libease). @BernhardDenner already did something like this within the ruby binding (see src/bindings/swig/ruby/kdbtools.* which is a binding for libtools).

But first steps first: for this release we should get the C API right.

Contributor

markus2330 commented Dec 14, 2017

Okay, if you are happy with its semantics and its name you can make it public as-is within libease. See doc/todo/API for what to consider (next to have the declaration in the header file).

For the binding: ideally you have two separated bindings (one for core, the other for libease). @BernhardDenner already did something like this within the ruby binding (see src/bindings/swig/ruby/kdbtools.* which is a binding for libtools).

But first steps first: for this release we should get the C API right.

@e1528532 e1528532 self-assigned this Jan 17, 2018

@e1528532

This comment has been minimized.

Show comment
Hide comment
@e1528532

e1528532 Jun 11, 2018

Contributor

This is already public since quite some time, thus closing this issue.

Contributor

e1528532 commented Jun 11, 2018

This is already public since quite some time, thus closing this issue.

@e1528532 e1528532 closed this Jun 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment