Does the package declared in the source file must match the directory hierarchy? For example, in source file a/b/c/foo.scala, the package must be a.b.c? If so, why bother to repeat again in the source file? If not, since the source file could declare any package it belongs to, then what's the usage of the directory hierarchy?
And is there some restriction about what could be inside the source file? For example, does the foo.scala could contain public class foo, and other classes or functions must be private or package access only?
Its not a requirement, but it the usual behaviour. A file a/b/c/foo.scala could be package x.y.z. I suppose you could say directories manage the way you store your code, and packages manage the way you expose your code.
There are no restrictions about what can be inside the source file (This is different to Java). foo.scala could contain the public class bar, or foo, or both, for example.
Related
In MATLAB, a class folder is represented by foo/#bar/ and a package folder is represented by foo/+bar. In my hierarchy, I have classes that define methods in separate files, so the #bar/ convention is necessary for their containing folders. However, I also have methods that get somewhat complex in their implementation, and would like to have them packaged into... well, packages using the +bar/ convention, like so:
foo/#classfolder/MyClass.m
foo/#classfolder/method1.m
foo/#classfolder/method2.m
foo/#classfolder/+othermethodstuff/method2helper.m
foo/#classfolder/+othermethodstuff/mexmethod_formethod2helper.m
foo/#classfolder/+othermethodstuff/mexfiles/
I want to do this because methods in my actual code that are represented here by method2.m rely on some heavy computations from MEX files that I would prefer to reside in their own folder, with the package system used by MATLAB keeping it clear when I am calling those methods (and from where).
Is this possible? If not, is my only other option dropping the # class folder convention and sticking everything into package (+) folders?
You should put those private implementation files in a subdirectory private. That is the traditional location for them. If you want to create some obvious hierarchy to organize code, I recommend long file names.
For example:
foo/#classfolder/MyClass.m
foo/#classfolder/method1.m
foo/#classfolder/method2.m
foo/#classfolder/private/physicssimulation_function1.m
foo/#classfolder/private/physicssimulation_function2.m
foo/#classfolder/private/physicssimulation_mexfile.mex
foo/#classfolder/private/uihelper_functionA.m
foo/#classfolder/private/uihelper_functionB.m
M-files and MEX-files in the private directory can be called from any function in the #classfolder directory, as if they were on the path (i.e. you don’t use private when calling them). But they are private to that directory, and not visible from outside.
The above recommendation assumes multiple class methods use the same private functionality. If only one method uses physicssimulation, then all of its functions should be inside that method’s M-file. It’s the better way of keeping code together.
I would like to structure my project in several packages. Each package should be each own namespace (so as to avoid conflicting filename) but within a package, I want everything to be in the same namespace (without having to put all the files in the same folder; I'd like different folders).
In practice I would like this structure
Project
main.m
commonLibrary
+part1Project
mainPart1.m
otherFolder
supportFile.m
+part2Project
mainPart2.m
otherFolder2
supportFile2.m
This is the behavious I would like:
When in main.m, I can call everything in common library and everything in any sub-project, including the functions inside the subfolder. So I would like to call part1Project.supportFile
When in mainPart1.m, I want to call the support files without using the prefix of the current package (i.e. I want to call supportFile directly)
When in mainPart2, I want to call supportFile2 directly. If I want access to files in the the part 1 of the project, I can call part1Project.supportFile.
The current setup is that I added the Project folder and all the subfolders to the matlab path. But this means that
I CANNOT call supportFile from anywhere; not from main (part1Project.supportFile will not work) and not even from mainPart1 (supportFile can't be found)
Much in the same way, it is hard to access elements of part1Project from part2Project
How can I achieve the behaviour I want?
You cannot access functions within a subfolder of a package unless that subfolder is a private folder in which case it will only be accessible to the functions in the immediate parent folder.
If you do use the private folder approach, then you can call functions within this private folder from the functions in the containing folder without using the fully-qualified package name.
Your layout would look like:
Project
main.m
commonLibrary
+part1Project
mainPart1.m
private
supportFile.m
+part2Project
mainPart2.m
private
supportFile2.m
Your first point will not work but the other two will. There is no built-in way to accomplish the first point.
Another option would be to use import statements in all functions within each package such that it imports all package members at the beginning of the function.
Your layout would look like
Project
main.m
commonLibrary
+part1Project
mainPart1.m
supportFile.m
+part2Project
mainPart2.m
supportFile2.m
And the contents of mainPart1.m (any any function) would look something like:
function mainPart1()
% Import the entire namespace
import part1Project.*
% No package name required
supportFile()
end
And then from main you could access supportFile
function main()
part1Project.supportFile()
end
In a library package, I would like to move some source files from the "Sources" folder to subdirectories, without changing language semantics (module name, visibility, etc).
Now I have a layout like:
LibraryProject
Sources
AnotherThing.swift
FooProtocol.swift
SomeFoo.swift
OtherFoo.swift
BarProtocol.swift
SomeBar.swift
OtherBar.swift
And, if I change it to something like:
LibraryProject
Sources
AnotherThing.swift
Foo
FooProtocol.swift
SomeFoo.swift
OtherFoo.swift
Bar
BarProtocol.swift
SomeBar.swift
OtherBar.swift
Then, invoking swift build fails:
error: the package has an unsupported layout, unexpected source file(s) found: [...]
Is this layout possible? I only found this issue https://bugs.swift.org/browse/SR-66 that suggests that it is not, but I cant find confirmation (or reason) in the documentation.
Thanks
I have found two options that work for Swift projects on Linux, either all .swift files must be directly in the Sources folder, or there must be one subfolder in Sources and as many subfolders within that as you like.
Swift builds a Module out of the top-level subfolder in Sources and includes all the subfolders within that.
I don't believe it is possible to have two Modules within the same Sources folder, as a Module would not recognise any code outside itself.
So in your example a working structure would be:
LibraryProject
Sources
YourModuleName
AnotherThing.swift
Foo
FooProtocol.swift
SomeFoo.swift
OtherFoo.swift
Bar
BarProtocol.swift
SomeBar.swift
OtherBar.swift
Here is the Folder structure for Swift package
And Here i have mentioned how to add the resources and add lines in Package
I have the following situation:
Consider that I have a class nested in a folder structure like for example /fol/der/exam/ple.java . Of course, the class ple.java contains package or import instuctions referencing to some sources. Now, when I choose Use as a source folder for /fol/der/exam/ple.java then, of course, the references used in package, import or function parameters are not the same anymore. I need to adjust them. Is there an elegant how to do that automatically in eclipse?
So, let´s assume that I have the following line in ple.java:
package fol.der.exam;
and that I have this line also in other files like a.java, b.java, etc. and I want to change the line, let´s say to package der.exam;
How can I do that automatically for all java files in eclipse?
best regards,
I have created a small Modelica library of my own. The way I have created it is in a single file. But I would like to make it a proper Modelica Library, as in the one with multiple directories for each subpackages.
So this is what i followed. File > New Modelica Class > Specialization - Package > Unchecked Save contents in one file. I copied the entire package code from the single file library, pasted it here and saved it. while doing so, I've noticed that the library lost most of its extends clauses, few models went missing.
Have I followed the correct procedure to create the library or did I do something wrong?
Can anyone point me towards the right direction?
#MSK, I cannot help you with OpenModelica as I work with Dymola. I did however recently split a single-file library (called package in Modelica) into several files manually. I did this so that the library hierarchy is represented in the file system hierarchy (i.e. several subfolders and .mo files in a library folder). For 35,000 lines of code this took roughly 10 hours. Just follow these steps:
create folder with same name as library
in this folder, create a text file "package.mo"
"package.mo" has to start with the statement
within ;
package [name of your package, i.e. the folder name...without the brackets];
now you want to create a subclass within this package. To do this create another folder containing a text file called "package.mo"
start this "package.mo" with
within [name of your package];
and declare the model as usual.
continue all the way down your library hierarchy
at the lowest hierarchy level you no longer need to create folders. You can simply create a .mo with the name of the lowest level class. As usual, start this file with
within [name of your package].[subclass1].[subclass2];
For an example of implementation please refer to the Physiolibrary found at https://www.modelica.org/libraries or the Modelica Standard Library which also uses this structure.