I have an interface SomeInterface implemented by classes A -> B -> C -> D where D directly implements SomeInterface and A through C are an hierarchy of extensions.
I am trying to find usages of SomeInterface in a specific module via Intellij's Find Usages interface.
It seems to find B, C, D, SomeInterface but does not find A.
Is there a limit to depth? I am of course checking "Derived interfaces" and "Implementing classes" checkboxes in the find options dialog (see screenshot).
Related
I am new to Kotlin and came across many instances in documentation where the common, js, native and jvm tags list different return values or class types. Could anyone please explain what exactly does that mean?
Here is an example:
My two question here are:
How are class, typealias and open class different?
Why do they seem to return different values for creating the same thing?
The documentation is telling you what you can expect the declaration of LinkedHashMap to look like, when writing code on different platforms - Kotlin/JS, Kotlin/JVM, Kotlin/Native. The "common" declaration is sort of the "intersection" of the other three - the "common" things among the three, which is useful if you are writing cross-platform code.
To explain each in detail (notice all 3 platforms is a "superset" of common):
Common:
class LinkedHashMap<K, V> : MutableMap<K, V>
LinkedHashMap is a class that has two generic parameters K and V, and it implements MutableMap<K, V>.
JVM:
typealias LinkedHashMap<K, V> = LinkedHashMap<K, V>
LinkedHashMap<K, V> is a typealias (i.e. another name) for Java's java.util.LinkedHashMap<K, V> class. The package name java.util is not shown in the documentation itself, which might be confusing, but you can click on the link to find out :)
Notice that java.util.LinkedHashMap<K, V> implements java.util.Map<K, V>, which when ported to Kotlin, means that it implements MutableMap<K, V>. (I say this because this is one of the things in the common declaration)
JS:
open class LinkedHashMap<K, V> :
HashMap<K, V>,
MutableMap<K, V>
LinkedHashMap is a class that has two generic parameters K and V, and it implements MutableMap<K, V>. It also inherits from HashMap<K, V>, and it is open, which means that you can inherit from it.
Native:
typealias LinkedHashMap<K, V> = HashMap<K, V>
LinkedHashMap<K, V> is just another name for HashMap<K, V> (this time it's Kotlin's kotlin.collections.HashMap, not Java's. Click the link to find out.) Also note that HashMap<K, V> implements MutableMap<K, V> too.
Why do they seem to return different values for creating the same thing?
These are not functions, and they don't return anything. These are declarations for the class LinkedHashMap, and some platforms may declare them differently, because they're different platforms! For example, why would Kotlin/JVM make an entirely new LinkedHashMap, when there is already one in the JDK? So they just say that kotlin.collections.LinkedHashMap is just another name for java.util.HashMap. Another example is Kotlin/Native: it appears that the HashMap that they implemented is already linked, so again, we don't need a totally new class.
As long as what they implement on these different platforms satisfy the requirements of the "common" declaration (namely two generic type parameters K and V, and implements MutableMap<K, V>), they're fine.
First and foremost, most of the information in the docs is not relevant, when on the JVM. If you type LinkedHashMap<String, String>(), you actually (because of the JVM only type alias) create a java.util.LinkedHashMap, thus the way the LinkedHashMap of kotlin is “implemented” on the JVM is using the java built-in. If you call linkedMapOf, however, you get back an instance of the kotlin.collections.LinkedHashMap<K, V> class, but if you look at the reflected type (::class) it is actually still a java.util.LinkedHashMap! So, we can conclude the following out of this:
On the JVM, collection types of the java stdlib are used (because the compiler changes constructor invocations to kotlin collections, to invocations of java ones)
There is a common class or interface that exists so you don’t have to write different code on different platforms, a different type may be used on runtime, however.
When using JS, LinkedHashMap can be overridden (because it is open), and it is the “implementer” of the expected LinkedHashMap type.
When using native targets, because the order is preserved when using a normal HashMap, LinkedHashMap points to there because there is no reason for using a linked hashmap instead of a normal one
Edit: just realized I didn’t really answer your question:
a class is just your regular oop class, but it can’t be overridden because it is open, typealias means that when you reference a certain type it actually “points” to a different type (you can see it as a type rename, or reexport), and an open class is a class that can be extended/overridden
Because of platform-specific implementations. This structure or expect + actual allows you to write common code for all platforms without having to worry about an individual platform.
I hope this answers your questions, let me know if you have any more.
I have a class, B, which has method foo(). I want to be able to answer: when B.foo() is called, which methods in another class A are in the call hierarchy?
A is a much, much lower-level class, so using IntelliJ's built-in call hierarchy hasn't worked for me - I can't manually browse the call tree so far down so many branches. Ideally, I'd like to filter the call tree to only branches which end with A.<something>(), to be able to say "when B.foo() is called, it might eventually call A.bar1() and A.bar3(), but not A.bar2(). Is there a built-in way to get this info?
How to print the interface library in cmake. Actually i want to do this for a debugging purpose.
so want to know how to print what are all the include directories in that interface library
I have a interface library A which is linked to 2 interface libraries B and C(i.e A includes B and C).
Now i want to know whether A contains all the paths are not..how to check that?
I have 2 classes: A,B. And A extends from B.
In my aspect I'm trying to declare parents for A and B to implements Serializable.
But for some reason, only B implements Serializable and A doesn't.
(See the orange arrow that is only on B)
image
If I switch the order between those lines, now A implements Serializable, and B doesn't.
(See the orange arrow that is only on B)
image
Why this is happening?
How can I make both of them implements Serializable?
I'm working on Eclipse Luna 4.4.2 with AspectJ 1.8.7.
Since A extends B, A inherits all implemented interfaces of it's superclass B. The declaration declare parents: A implements Serializable; hence does nothing, since A already implements Serializable through B.
I am new to CMake and a bit confused with the PUBLIC, PRIVATE and INTERFACE keywords related to target_link_libraries(). Documentation mentions that they can be used to specify both the link dependencies and the link interface in one command.
What does link dependencies and link interface actually mean?
If you are creating a shared library and your source cpp files #include the headers of another library (Say, QtNetwork for example), but your header files don't include QtNetwork headers, then QtNetwork is a PRIVATE dependency.
If your source files and your headers include the headers of another library, then it is a PUBLIC dependency.
If your header files other than your source files include the headers of another library, then it is an INTERFACE dependency.
Other build properties of PUBLIC and INTERFACE dependencies are propagated to consuming libraries. http://www.cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#transitive-usage-requirements
#steveire accepted answer is great. I just wanted to add a table to quickly see the difference:
.-----------.------------------.----------------.
| | Linked by target | Link interface |
:-----------+------------------+----------------:
| PUBLIC | X | X |
:-----------+------------------+----------------:
| PRIVATE | X | |
:-----------+------------------+----------------:
| INTERFACE | | X |
'-----------'------------------'----------------'
Linked by target: libraries included in target sources (not a dependency for projects linking the library).
Link interface: libraries included in target public headers (dependencies for projects linking the library).
Not my brainchild but this extremely useful explanation helped me understand the situation. The most important part is quoted below for reference:
When A links B as PRIVATE, it is saying that A uses B in its implementation, but B is not used in any part of A's public API. Any
code that makes calls into A would not need to refer directly to
anything from B. An example of this could be a networking library A
which can be built to use one of a number of different SSL
libraries internally (which B represents). A presents a unified
interface for client code which does not reference any of the
internal SSL data structures or functions. Client code would have
no idea what SSL implementation (B) is being used by A, nor does
that client code need to care.
When A links B as INTERFACE, it is saying that A does not use B in its implementation, but B is used in A's public API. Code
that calls into A may need to refer to things from B in order to
make such calls. One example of this is an interface library which
simply forwards calls along to another library but doesn't actually
reference the objects on the way through other than by a pointer or
reference. Another example is where A is defined in CMake as an
interface library, meaning it has no actual implementation itself,
it is effectively just a collection of other libraries (I'm
probably over-simplifying here, but you get the picture).
When A links B as PUBLIC, it is essentially a combination of PRIVATE and INTERFACE. It says that A uses B in its implementation and
B is also used in A's public API.
Consider first what this means for include search paths. If something
links against A, it will also need any include search paths from B if
B is in A's public API. Thus, if A links B either as PUBLIC or
INTERFACE, then any header search paths defined for target B will also
apply to anything that links to A. Any PRIVATE header search path for
B will NOT be carried through to anything that links only to A. The
target_include_directories() command handles this. The situation with
compile flags is analogously handled with target_compile_definitions()
and target_compile_options().
Now consider the situation for the actual libraries involved. If A is
a shared library, then A will have encoded into it a dependency on B.
This information can be inspected with tools like ldd on Linux, otool
on Mac and something like Dependency Walker (a.k.a. depends.exe) on
Windows. If other code links directly to A, then it also will have
encoded into it a dependency on A. It will not, however, have a
dependency on B unless A links B either as PUBLIC or INTERFACE. So far, so
good. If, however, A is a static library, the situation changes.
Static libraries do not carry information about other libraries they
depend on. For this reason, when A links B as PRIVATE and another
target C links A, CMake will still add B to the list of libraries
to be linked for C because parts of B are needed by A, but A itself
doesn't have that dependency encoded into it. So even though B is an
internal implementation detail of A, C still needs B added to the
linker command, which CMake conveniently handles for you.
If you were paying careful attention, you would have noticed that when
A links B as PRIVATE, the include directories of B never propagate
to something linking to A, but if A is a static library, then the
linking of B behaves as though the relationship was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to
the
linking, not to the other dependencies (compiler options/flags and include search paths). The upshot of all this is that if you select
PRIVATE, PUBLIC or INTERFACE based on the explanations in the dot
points above, then CMake will ensure dependencies propagate through to
where they are required, regardless of whether libraries are static or
shared. This does, of course, rely on you the developer not missing
any dependencies or specifying the wrong PRIVATE/PUBLIC/INTERFACE
relationship.
Some answers only said when to use PRIVATE/PUBLIC/INTERFACE, but the affects are ignored. Refer:CMake-Public-Private-Interface
PUBLIC
All the objects following PUBLIC will be used for linking to the current target and providing the interface to the other targets that have dependencies on the current target.
PRIVATE
All the objects following PRIVATE will only be used for linking to the current target.
INTERFACE
All the objects following INTERFACE will only be used for providing the interface to the other targets that have dependencies on the current target.
Other posts already answered what the meaning of PUBLIC/PRIVATE/INTERFACE keywords. I want to add one more to clarify the terms "link dependencies" and "link interface."
Link dependencies :
the list of libraries to be linked by the target.
The target property LINK_LIBRARIES holds this information.
Link interface : the list of libraries to be linked by the target's dependents. The target property INTERFACE_LINK_LIBRARIES holds this information.
Probably the term "link interface" came from the old CMake wording used around LINK_INTERFACE_LIBRARIES properties, which is deprecated in favor of INTERFACE_LINK_LIBRARIES.
See the description of CMP0022, which also uses the term "link interface."
https://cmake.org/cmake/help/latest/policy/CMP0022.html
INTERFACE_LINK_LIBRARIES defines the link interface.