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

syscall: mksyscall_windows.go should be possible to work on internal package #9635

Closed
mattn opened this issue Jan 19, 2015 · 9 comments
Closed

syscall: mksyscall_windows.go should be possible to work on internal package #9635

mattn opened this issue Jan 19, 2015 · 9 comments
Milestone

Comments

@mattn
Copy link
Member

@mattn mattn commented Jan 19, 2015

Related issue #5395

When add new APIs into internal/syscall, we can't use mksyscall_windows.go like below.

internal/syscall_windows.go

package syscall

import (
  stdsyscall "syscall"
)

//sys ...
@minux
Copy link
Member

@minux minux commented Jan 19, 2015

The generation of syscall wrappers is not automatic, so you need to add a
go:generate comment.

//go:generate go run ../../syscall/mksyscall_windows.go -output
zsyscall_windows.go syscall_windows.go

And then run go generate.

@mattn
Copy link
Member Author

@mattn mattn commented Jan 19, 2015

it doesn't use name stdsyscall. will be compile error.

On 1/20/15, Minux Ma notifications@github.com wrote:

The generation of syscall wrappers is not automatic, so you need to add a
go:generate comment.

//go:generate go run ../../syscall/mksyscall_windows.go -output
zsyscall_windows.go syscall_windows.go

And then run go generate.


Reply to this email directly or view it on GitHub:
#9635 (comment)

  • Yasuhiro Matsumoto
@mikioh mikioh changed the title mksyscall_windows.go should be possible to work on internal package syscall: mksyscall_windows.go should be possible to work on internal package Jan 19, 2015
@minux
Copy link
Member

@minux minux commented Jan 19, 2015

OK. I see.

We have at least three choices:

  1. Add a flag to mksyscall program
  2. Add NewLazyDLL and Syscall9 wrapper to internal/syscall. One extra level
    of indirection won't hurt much as the overhead of cgocall is much higher.
  3. Dot import syscall in internal/syscall. This might be ugly, but it is
    probably fine in this case as we are extending existing syscall package and
    it will also prevent us from redefining existing symbols in the original
    syscall package.

I like the 3rd option best.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Jan 19, 2015

@minux you are forgetting another option. We are calling new package internal/syscall/windows and then we don't need to do anything.

Alex

@minux
Copy link
Member

@minux minux commented Jan 19, 2015

But I don't agree with that package name. Just having to import it under
another name when another package with the same name is in use is not
strong enough to change the package name. And it's possible to only use the
internal/syscall package alone if it's self-sufficient enough (like the
current internal/syscall package).

Think text/template and html/template for example.

@mattn
Copy link
Member Author

@mattn mattn commented Jan 19, 2015

My best is mixin

On 1/20/15, Minux Ma notifications@github.com wrote:

But I don't agree with that package name. Just having to import it under
another name when another package with the same name is in use is not
strong enough to change the package name. And it's possible to only use the
internal/syscall package alone if it's self-sufficient enough (like the
current internal/syscall package).

Think text/template and html/template for example.


Reply to this email directly or view it on GitHub:
#9635 (comment)

  • Yasuhiro Matsumoto
@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Jan 19, 2015

Think text/template and html/template for example.

Not a good example. These two are never imported into the same source file. I would say think syscall and golang.orx/x/sys/windows instead.

Good names are important. I would like to decide on best possible name now and not to have that bikesheding every time we use these 2 packages together.

Alex

@minux
Copy link
Member

@minux minux commented Jan 20, 2015

How could you be so sure that text/template and html/template are never
used in the same file?

I've found about 120 packages that import both packages (of about 2k and
2.1k packages that import either of them). And the first three common
packages happen to all import them in the same file. Renaming a package is
not as rare as you might have expected.

https://camlistore.googlesource.com/camlistore.git/+/master/website/camweb.go
https://github.com/bosun-monitor/bosun/blob/master/cmd/bosun/conf/conf.go
https://bitbucket.org/phlyingpenguin/collectinator/src/default/common/http.go

Similar name collision happen with net/http/pprof and runtime/pprof,
go/scanner and text/scanner, crypto/rand and math/rand. That's the example
in the std packages.

If you don't want renaming syscall package, you can only use it in a new
file, as long as we design internal/syscall in a way that the user are not
required to also import syscall, that should be fine too.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 2, 2017

I believe @alexbrainman fixed this already.

@bradfitz bradfitz closed this Feb 2, 2017
@golang golang locked and limited conversation to collaborators Feb 2, 2018
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
6 participants
You can’t perform that action at this time.