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

h package #10

Open
shogg opened this issue Sep 28, 2024 · 3 comments
Open

h package #10

shogg opened this issue Sep 28, 2024 · 3 comments

Comments

@shogg
Copy link

shogg commented Sep 28, 2024

In the examples I saw you use the h-package. What is this naming? Don't burn commonly used symbols. Call it htmgo or something like that.

@maddalax
Copy link
Owner

maddalax commented Sep 28, 2024

What are you concerned about specifically? If you need to use 'h', you could alias it

htmgo "github.com/maddalax/htmgo/framework/h"
. "github.com/maddalax/htmgo/framework/h"

having it end with htmgo is too verbose for creating the markup, which would essentially force everyone to alias it by default anyway

@shogg
Copy link
Author

shogg commented Sep 28, 2024

I didn't know the h-package is for creating markup. Is it part of a markup language?
"Too verbose package name forces everyone to alias it by default." It forces you or it gives you the choice to leave the long name. With a one letter package name you're more often forced to alias it.
This was my last comment. You can close the issue as you like.

@maddalax
Copy link
Owner

I didn't know the h-package is for creating markup. Is it part of a markup language?

Yep, the h package in htmgo includes all the tags and attributes

h.Div
h.Button
h.Id
h.Class
etc...

With a one letter package name you're more often forced to alias it.

Appreciate the feedback but I'm not totally convinced its common enough to have one letter variable names such as 'h' to facilitate needing to alias very often.

Even if I was writing a triple for loop using single letter variable names, I would use the standard ijk

I'll keep this issue open just in case there are more arguments in favor of renaming it, but this is where I stand on it at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants