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

Gen on builtin types #89

Open
james-m opened this issue May 28, 2015 · 4 comments
Open

Gen on builtin types #89

james-m opened this issue May 28, 2015 · 4 comments

Comments

@james-m
Copy link

james-m commented May 28, 2015

Hello,

Sorry if this question is answered somewhere in the docs / another issue, I was unable to find if this is currently possible.

Basically, I would like generate slices on builtin types... I'm working around it by creating type which are just aliases of the builtin, then going into the generated code and doing a find-and-replace of the function params/return values. Blek!

So, for example, I have this:

//+gen set
type String string

I run gen, which creates the string_set.go file, which I then go in and change String back to string (where it makes sense).

Any thoughts? Thanks very much.

@clipperhouse
Copy link
Owner

I don’t know a good way to do this (have wanted for myself too). Aliasing is the “supported” way – gen’s supported use case is for local (package) types only.

The issue is, how does one add a gen directive (comment) to a built-in type? I think this might be better implemented as a whole separate package – “genp” for primitives, or something.

@hieuht817
Copy link

hieuht817 commented Sep 1, 2016

I would love it can gen on any types: built-in, 3rd-party, local...
Why does it need coupling the directive with the type's source code?

@artwyman
Copy link

This is an awkward workaround, but could you avoid this with a custom TypeWriter which ignored its primary Type and just took all of its type parameters from tag values? e.g.

// +gen myset:"ValueType[string]"
type DummyType struct{}

This is awkward in that the myset typewriter would need to duplicate what "set" already does except with different paramters, and also because DummyType only exists as a place to attach an annotation.

FWIW I think gen is awesome, but this limitation is pushing me away from it as a solution vs. other alternative generators out there. I'd like to support generators on primitive types (like generating min/max functions), and generators which need multiple parameters (like TreeMap<K,V>). The workaround here seems too awkward for me to want to sell to other developers. It would be nice if gen could support this directly with a direct way to specify the "primary type" in an annotation without being attached to it, such as what was suggested in #99.

@clipperhouse
Copy link
Owner

@artwyman Thanks for using gen! It does parse multiple type parameters, and they are exposed on TagValue.

Yeah, my biggest blocker for primitive types is the notation — there is no type declaration to mark up. I like the markup to be in the repo, near the type. Easily understandable, self-documenting.

I’m not a huge fan of command-line args though I suppose it’s not the end of the world. It means that definitions (potentially) live outside the repo, and far from the type, and it’s a little harder to give good feedback on errors.

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

4 participants