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

builtin: New function for resource loading #4623

Closed
eaigner opened this issue Jan 6, 2013 · 10 comments
Closed

builtin: New function for resource loading #4623

eaigner opened this issue Jan 6, 2013 · 10 comments

Comments

@eaigner
Copy link
Contributor

@eaigner eaigner commented Jan 6, 2013

It would be useful if the go compiler provided a mechanism for compiling resources into
the binary, and accessing them via a builtin function.

Proposal to add the following function to the builtin package:

    // resource loads a resource by name. Resources can be compiled into the binary by naming them
    // accordingly, e.g.
    //
    //    index.html.gores                     => resource("index.html")
    //    templates.gores/index.html    => resource("templates/index.html")
    //
    resource(name string) []bytes
@minux
Copy link
Member

@minux minux commented Jan 6, 2013

Comment 1:

I'd rather not build these kind of things into the language.
maybe we can figure out a way for the go tool to do some
kind of asset packing, but I'm not sure about that either.

Labels changed: added languagechange.

@eaigner
Copy link
Contributor Author

@eaigner eaigner commented Jan 6, 2013

Comment 2:

I'm not sure if that's a good/plausible approach either, just trying to get a
conversation started, since I don't seem to be the only one that would love to add some
resources to the binary more conveniently.

@cznic
Copy link
Contributor

@cznic cznic commented Jan 6, 2013

Comment 3:

I don't like this approach (cf. built-in compiler magic function).

@eaigner
Copy link
Contributor Author

@eaigner eaigner commented Jan 6, 2013

Comment 4:

What's "magic" with this approach?
The only difference is that the compiler would assign the binary contents of a file to
some variable instead of parsing code and then doing exactly the same with a constant.
It would just expand on concepts that go already uses for specific architectures (e.g.
"_<arch>.go").

@minux
Copy link
Member

@minux minux commented Jan 6, 2013

Comment 5:

FYI, the _$GOARCH.go naming convention is provided by the go tool.
the core Go language doesn't know that (in fact, the gc compiler
won't complain if you feed a valid Go program with a .html filename
suffix to it)

@cznic
Copy link
Contributor

@cznic cznic commented Jan 6, 2013

Comment 6:

@4: 1) A built-in compiler magic function is a function which cannot be written in the
by-the-compiler-accepted-language per se, in case of Go e.g. `new`, `append`, `make`,
len, ...
2) That's the essence of "I don't like this approach".
3) IMO not. `_<arch>` is external to both the language as it is to any
built-ins/predeclared stuff.

@eaigner
Copy link
Contributor Author

@eaigner eaigner commented Jan 6, 2013

Comment 7:

I never said `_<arch>` was part of the language, i said it was a concept!

@rsc
Copy link
Contributor

@rsc rsc commented Jan 6, 2013

Comment 8:

Adding a builtin is a language change. This doesn't merit a language change.
If we need to support baked-in copies of binary data - and that's
unclear to me - then it would be easy to define:
package resource
func Load(name string) ([]byte, error)
func Install(name string, data []byte)
and then have the "resource compiler" arrange to call resource.Install
during a func init. No language change needed.
However, I am not suggesting that we do this. It's a big topic and
it's unclear that that's the right API. I'm merely pointing out that
it doesn't require a language change.
Russ

@rsc
Copy link
Contributor

@rsc rsc commented Jan 7, 2013

Comment 9:

The golang-nuts discussion points out 
    https://bitbucket.org/tebeka/nrsc
    https://github.com/jteeuwen/go-bindata

Status changed to WontFix.

@eaigner
Copy link
Contributor Author

@eaigner eaigner commented Jan 7, 2013

Comment 10:

Yes, but this is a request for a standardized method to do this that is automatically
run on build - not by invoking a 3rd party binary afterwards.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants