Skip to content
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

Enforce naming conventions #671

Closed
cdavernas opened this issue Sep 9, 2022 · 7 comments · Fixed by #768
Closed

Enforce naming conventions #671

cdavernas opened this issue Sep 9, 2022 · 7 comments · Fixed by #768
Assignees
Labels
area: spec Changes in the Specification change: feature New feature or request. Impacts in a minor version change
Milestone

Comments

@cdavernas
Copy link
Member

cdavernas commented Sep 9, 2022

What would you like to be added:

Enforce naming conventions of most (if not all) components.

I propose that we enforce using snake and/or kebab cased names.

Why is this needed:

In the case of functionDefs of type expression, for example, not enforcing a naming convention makes expression parsing a huge mess.

Consider the following example:

functions:
  - name: Say Hello
    type: expression
    operation: 'Hello!'

Now to call the function in an expression as defined by the spec, you'd need to write something like:

. | . * { "greetings": "fn:Say Hello" }

... which is impossible to parse both properly and/or safely. We could of course mandate to put the function's name between parenthesis (ex: $fn:(Say Hello)), for example, but I think the easier and cleanier approach is to go with a naming convention

@tsurdilo tsurdilo added the change: feature New feature or request. Impacts in a minor version change label Sep 12, 2022
@tsurdilo tsurdilo added this to the v0.9 milestone Sep 12, 2022
@tsurdilo
Copy link
Contributor

Agree, will do pr for it

@cdavernas cdavernas added the area: spec Changes in the Specification label Sep 13, 2022
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@ricardozanini
Copy link
Member

Let's use Kubernetes convention for naming: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

They are based on RFC1123, so it's safe for DNS too.

@cdavernas cdavernas moved this from Todo to In Progress in Progress Tracker May 26, 2023
@cdavernas cdavernas linked a pull request May 26, 2023 that will close this issue
9 tasks
@cdavernas cdavernas moved this from In Progress to Backlog in Progress Tracker May 30, 2023
@cdavernas cdavernas moved this from Backlog to In Progress in Progress Tracker May 30, 2023
@fjtirado
Copy link
Collaborator

fjtirado commented Jun 7, 2023

Let's use Kubernetes convention for naming: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

They are based on RFC1123, so it's safe for DNS too.

Hmmm, I think we should support _ for naming, without the need of escaping it

@fjtirado
Copy link
Collaborator

fjtirado commented Jun 7, 2023

I think we should allow _ in the id, there is always the possibility of mapping it to - when being used as k8s label. Besides that I think ids can include more special characters than functions (-,_,&,!)
For functions, as a developer, I would ban most of special characters: &, |, @, &, ?, $, (, ), {,}, [,], +, -, because they might appear in a jq expression, so to make things simpler I vote for snake (which uses _, not -, which might be interpreted as minus operation) and allowing the same chars that JQ does (letter, numbers and of course _)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: spec Changes in the Specification change: feature New feature or request. Impacts in a minor version change
Projects
Status: Done
4 participants