-
Notifications
You must be signed in to change notification settings - Fork 25
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
Is not yet specified package and utils #667
Comments
Yes, I like that idea. We would really need to run it past the Language Board, but it is a sensible addition rather than a change. |
@nickbattle why do we need to run it past the LB? The way I understand this, it's just an internal change in the Delegate class, isn't it? |
Well yes, but if we want all future native libs to be in a particular Java package structure, that would have to be added to the packaging guidelines? |
Ah yes, I see. |
… found in first attempt #667 added missing class check
Okay so it is implemented. Can we close this issue, or do we need to add something on the Language Board library submission workflow page? |
Or perhaps update the LRM or guides, if they talk about the package structure for native library loading? |
I can't find anything in the LRM, but there's a related section in the Overture user manual: 16.2 Defining Your Own Java Libraries to be used from Overture. This section describes the naming convention used for packages (>>The Java delegate, if present, has the same name as the VDM module/class name with underscores ("_") replaced with package naming dots (".").<<. We could add an extra paragraph in this section that describes the new loading strategy. What do you think? |
This needs raising with the LB (next year!). |
Would it be possible to change the Delegate loading from using no package to a package like
org.overture.lib
or search default first and then this package?There are some utility methods like
stringOf(Value val)
that I keep repeating in different places because I cannot referIO
since it has no package.The method is also not exposed but thats not a problem to fix if the class just had a package.
I think that leaving these classes without a package isn't the best approach in the first place and I dont think that we would change any backwards compatibility if we just search both for a match.
The text was updated successfully, but these errors were encountered: