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

Drop 'private' on demand? #13

Open
sebastiansturm opened this issue May 26, 2017 · 5 comments
Open

Drop 'private' on demand? #13

sebastiansturm opened this issue May 26, 2017 · 5 comments

Comments

@sebastiansturm
Copy link

Hi,

I'd like to redeclare many of my currently abstract types as private so their contents are visible to ocamldebug. If ppx_import allowed me to change an imported type's visibility from private to public on demand, I could do that with a lot less redundant typing. Do you think such a feature could be added (maybe by resurrecting the commit prior to #8 and exposing it via another directive such as %import_dropping_private)? Or maybe there already is a way to achieve that with the current version of ppx_import which I am not aware of?
thanks,
Sebastian

@whitequark
Copy link
Contributor

I'm confused. Can you show me a minimal example with your current code, and with your desired code? Also, ppx_import adds a manifest type so I think if ppx_import did what you want it'd not typecheck.

@sebastiansturm
Copy link
Author

sure, let's say I have a module named Test, where Test.mli contains the following:
type t = private A of int | B (* not declared abstract as that would render ocamldebug relatively useless *) (* ... function declarations follow *)
Within Test.ml, I'd now have to completely replicate the declaration of t, up to the keyword 'private':
type t = A of int | B (* ... etc ... *)
That way, the internals of Test.t are (IMHO) reasonably well-isolated from the outside world while still allowing for convenient introspection via ocamldebug. What I'd like to do is to replace the type definition within Test.ml by type t = [%import: Test.t]. As that import directive now no longer drops the private keyword, however, t is isolated even from Test.ml itself, which prevents me from doing anything useful with it.

I had expected this to be possible, as it seems to be pretty close to what test_self_import does?

@whitequark
Copy link
Contributor

Ohh you mean importing from own mli! There should just be a branch that if you import from your own mli then private should be dropped. Because there is no way to construct this type otherwise.

@sebastiansturm
Copy link
Author

that would be awesome :)

@whitequark
Copy link
Contributor

I have no plans to implement this but you are welcome to submit a PR. Such a change should be fairly trivial.

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