Official docs on visibility modifiers in Kotlin say that package-level elements marked private are be visible only in the module in which they are declared.
So class A declared in Module1.kt isn't visible in Module2.kt. But if I try to add to Module2.kt it's own class A I get the Redeclaration: A error.
Since I can't access in Module2.kt to Module1's A class, why isn't the name A free to use?
"A module is a set of Kotlin files compiled together" (Visibility Modifiers - Kotlin Programming Language).
In your example, Module1.kt and Module2.kt are separate source files and despite their names they are not necessarily part of separate modules:
If they are compiled together then they are part of the same module.
If they are compiled separately from one another then they will be part of different modules and each can define their own private class A.
Keep in mind that visibility is different from identity. Even if a class is not visible elsewhere it doesn't mean that it does not exist. Loading multiple class declarations with the same fully-qualified name can (and likely will) cause issues at run-time.
Related
android has the concept of a linker namespace.
https://source.android.com/devices/architecture/vndk/linker-namespace
what exactly is a linker namespace in layman terms ?
when would we want to use dlmopen vs dlopen ?
what use case is dlmopen trying to solve that dlopen does not solve ?
The project I work on makes use of dlXXX API for loading shared libraries at runtime and we want to ensure that the symbols loaded from the shared library are completely isolated. Does dlmopen address this issue ?
from dlopen's man page :
The dlmopen() function differs from dlopen() primarily in that it ac‐
cepts an additional argument, lmid, that specifies the link-map list
(also referred to as a namespace) in which the shared object should be
loaded. (By comparison, dlopen() adds the dynamically loaded shared
object to the same namespace as the shared object from which the
dlopen() call is made.) The Lmid_t type is an opaque handle that
refers to a namespace.
The lmid argument is either the ID of an existing namespace (which can
be obtained using the dlinfo(3) RTLD_DI_LMID request) or one of the
following special values:
LM_ID_BASE
Load the shared object in the initial namespace (i.e., the ap‐
plication's namespace).
LM_ID_NEWLM
Create a new namespace and load the shared object in that name‐
space. The object must have been correctly linked to reference
all of the other shared objects that it requires, since the new
NOTES
dlmopen() and namespaces
A link-map list defines an isolated namespace for the resolution of
symbols by the dynamic linker. Within a namespace, dependent shared
objects are implicitly loaded according to the usual rules, and symbol
references are likewise resolved according to the usual rules, but such
resolution is confined to the definitions provided by the objects that
have been (explicitly and implicitly) loaded into the namespace.
The dlmopen() function permits object-load isolation—the ability to
load a shared object in a new namespace without exposing the rest of
the application to the symbols made available by the new object. Note
that the use of the RTLD_LOCAL flag is not sufficient for this purpose,
since it prevents a shared object's symbols from being available to any
other shared object. In some cases, we may want to make the symbols
provided by a dynamically loaded shared object available to (a subset
of) other shared objects without exposing those symbols to the entire
application. This can be achieved by using a separate namespace and
the RTLD_GLOBAL flag.
The dlmopen() function also can be used to provide better isolation
than the RTLD_LOCAL flag. In particular, shared objects loaded with
RTLD_LOCAL may be promoted to RTLD_GLOBAL if they are dependencies of
another shared object loaded with RTLD_GLOBAL. Thus, RTLD_LOCAL is in‐
sufficient to isolate a loaded shared object except in the (uncommon)
case where one has explicit control over all shared object dependen‐
cies.
Possible uses of dlmopen() are plugins where the author of the plugin-
loading framework can't trust the plugin authors and does not wish any
undefined symbols from the plugin framework to be resolved to plugin
symbols. Another use is to load the same object more than once. With‐
out the use of dlmopen(), this would require the creation of distinct
copies of the shared object file. Using dlmopen(), this can be
achieved by loading the same shared object file into different name‐
spaces.
The glibc implementation supports a maximum of 16 namespaces.
So yes, it can be used to isolate a loaded lib !
How does JVM loads class that are defined inside another class?
Example: Lets say, there is a class B that is defined inside class A
package test.sample;
Class A {
// some instructions
Class B {
// few more instructions
}
}
In this case,
How does classloader load the class B? (i.e., How does it identify class B?)
What will be the fully qualified name of class B?
Inner classes are a Java language feature, not a JVM feature. That is, Java compilers "flatten" the class structure, so the JVM just sees regular classes, usually with $ in their names. In this case, there would be classes test.sample.A and test.sample.A$B (the latter being the fully qualified name of B). Anonymous inner classes get compiler-defined names, typically starting at 1 and counting up: test.sample.A$6, for example. The compiler may add methods with names like access$200 to allow the enclosing class and inner class to access each others' private members. (Note that $ is legal, though discouraged, in user-defined class and method names, so the presence of a $ in a name does not mean it is compiler-generated; for that, there's the Synthetic attribute and ACC_SYNTHETIC modifier bit, exposed reflectively via methods like Class.isSynthetic().)
The JVM loads these classes just like any other class, typically looking for a file test/sample/A$B.class in some JAR file, but also possibly loading them across a network, generating them on-the-fly with a bytecode manipulation library, etc.
When generating class files that reference an inner class (defining, containing, or simply using), Java compilers emit InnerClasses attributes specifying the containment relationships, for the aid of separate compilation and reflection (Class.getDeclaringClass() and Class.getEnclosingClass()). Class files for classes defined inside a method also contain an EnclosingMethod attribute referring to the enclosing method, for reflection (Class.getEnclosingMethod() and Class.getEnclosingConstructor()). However, these attributes are only checked for syntactic well-formedness by the JVM during loading and linking; inconsistencies are not reported until the reflective methods are actually called.
I have two frameworks in my Xcode project that both define a class with the same name (B.framework and C.framework both have a class named MyClass), resulting in a couple warnings like so:
Duplicate symbol _OBJC_METACLASS_$_MyClass originally in B.framework/B(MyClass.o) now lazily loaded from C.framework/C(MyClass.o)
Duplicate symbol _OBJC_CLASS_$_MyClass originally in B.framework/B(MyClass.o) now lazily loaded from C.framework/C(MyClass.o)
Then at run time only one of the implementations is loaded, and trying to use the other one will result in a "unrecognized selector sent to instance" because they are totally different classes (even though they have the same name).
I use one of the MyClass implementations directly in my code, but the other framework only uses its MyClass internally and I have no idea why its even exported (its not even mentioned in the frameworks header files, i used nm to view the symbols).
How can I make both frameworks work?
There's no such thing as "exported" classes in Obj-C. Or rather, there's no such thing as "non-exported" classes. This problem is precisely why the use of 2- or 3-letter prefixes on classes is strongly recommended for all Obj-C code. Your only solution (besides not using these frameworks) is to edit one (or both) of the frameworks to change the class name, or if you don't have access to the source, then you need to contact the vendor and ask them to make that change.
My VB project is large enough that it requires several files. It was originally developed as a Console App and I created each file as a MODULE. All modules could use subroutines, data structures and constants from other MODULES and everything worked fine. I needed to add basic windowing to the app and this required that the app be converted from a Console App to a Windows Forms App. The main window is Form1 which is not a MODULE but a CLASS. The problem is that some MODULE based functions cannot access subroutines, data and constants that are defined within the CLASS Form1 unless they are incorporated into the CLASS file and this makes the CLASS file very large. If I add a new Class file to the project, it also cannot interoperate with Class Form1 in the same way that multi-MODULE code interoperates.
How does one spread CLASS code across several files and still allow it to interoperate as if it were in a single file? Alternatively, how does one create several CLASS files that operate the way multiple MODULE files operate.
I am sure that there are all kinds of best practices that I am violating but the goal to to get some prototype software working and interfaced to some lab equipment.
Thank you in advance
Use a partial class (Partial keyword on the class declaration). Each partial "bit" of the class will be merged at compile time. All partial bits must be in the same project.
Modules are default shared and do not require initialization with the New keyword. When you made your console app a windows app, it became a class...You could change it to the same behavior as a module simply by making it a Public shared Class and making all properties and methods inside shared as well.
so while you can access your methods and properties in your modules without initialization, you would need to use the NEW method to initialize your Class methods.
To access the Class from the module you would simply have to use:
SomeModulemethod
dim x as new CLASS
CLASS.SOMEMETHOD
someModuleMethod End
You could also use Partial Classing to split up your Classes, but it is much better to decide if you really need a separate class for what you want to do.
How can we distinguish to create a class which is static?
A static class forces all of its methods to be static and prohibits an instance constructor therefor can't be instantiated. If your question extends to WHEN to use static and WHEN instance, please do a search on StackOverflow (or check out the Related box on this page)
At least in C#,
static classes and class members are used to create data and functions that can be accessed without creating an instance of the class.
If you want the class to be static in nature i.e. have only 1 copy within the program (VM) then there are two obvious mechanisms:
1. Make all members and methods of the class static (Java/C#).
2. Use Singleton design pattern.
For this case (static in nature), we don't have a language construct and hence one of the above technique is used.
As to your question for this case, such classes should be created if you want your functionality to be accessible globally, unchanged and instantly accessible e.g. utility methods, global constants etc.
Secondly, the keyword 'static' is used with classes to increase their visibility in the package. This keyword can only be applied on inner classes and allows the access to inner classes without the context of their parent class.
Such kind of static classes should be used only for those inner classes that serve their purpose within the parent class as well as are useful outside the class or the package e.g. Key of a POJO.