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

Private Modules and useless default #1476

Open
bobot opened this issue Oct 18, 2018 · 7 comments
Open

Private Modules and useless default #1476

bobot opened this issue Oct 18, 2018 · 7 comments

Comments

@bobot
Copy link
Collaborator

bobot commented Oct 18, 2018

It is useful to hide all the modules except a small number because:

  • it gives better control on what is accessible
  • it allows to simulate pack by hiding all except the main module.

The default value of private modules is the empty set, so we can't say all except some. In #106, which have been reverted, the field was positive public_interfaces so the default set was all the modules.

Is the analysis correct?

@rgrinberg
Copy link
Member

Yeah, the analysis is correct. I thought about another way of improving the default. Whenever the user writes a lib interface module, all the other modules should be marked as private by default. This would only improve the situation for (wrapped true) libraries but I think (wrapped false) is a lost cause anyway.

@rgrinberg
Copy link
Member

Whatever concrete suggestions we go with btw, I do agree that we should flip the private/public default for dune 2.0

@bobot
Copy link
Collaborator Author

bobot commented Oct 19, 2018

Whenever the user writes a lib interface module, all the other modules should be marked as private by default.

When an LIB_NAME.mli is given to the library or also when a LIB_NAME.ml is given? But I think an explicit choice would be simpler.

We could:

  • add a public_modules field which is mutually exclusive with private_modules. They define the same thing.
  • add a :all to private_modules

@emillon
Copy link
Collaborator

emillon commented Oct 19, 2018

I think that we could do the following:

  • define public_modules as an OSL field (with :standard meaning every module)
  • define (private_modules x) as a shortcut for (public_modules :standard \ x)

@bobot
Copy link
Collaborator Author

bobot commented Oct 19, 2018

@emillon I like the definition as a shortcut it simplifies the documentation.

@rgrinberg
Copy link
Member

When an LIB_NAME.mli is given to the library or also when a LIB_NAME.ml is given? But I think an explicit choice would be simpler.

Either one is considered as providing a lib interface module.

Okay so I think @emillon's suggestion is best. Just to clarify, the two fields will be mutually exclusive, right?

For dune 2.0, we can change the value of :standard to be just the name of lib interface module so that the default is more conservative. There's no need to touch the default for (wrapped false).

@emillon
Copy link
Collaborator

emillon commented Oct 19, 2018

Just to clarify, the two fields will be mutually exclusive, right?

Yes!

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

No branches or pull requests

3 participants