Which Scala features are internally implemented using reflection? - reflection

It is a well known fact that structural types are implemented through reflection. Are there maybe any other language constructs which use reflection?

This is closely related to structural types, but any anonymous object instance, ie
new { def print = ("hello world") }.print
will use reflection.
http://scala-programming-language.1934581.n4.nabble.com/Structural-types-reflection-td3071599.html

Enumerations use reflection to find out about all of the possible values for the enumeration for the nameOf function. (See the populateNameMap method in Enumeration.scala). This is done once, the first time you call nameOf for a particular Enumeration type.

If you consider isInstanceOf/asInstanceOf as reflection, then pattern matching relies on them

Method invocation in structural types depends on reflection:
type T = { def startsWith(x:String):Boolean }
def doSomethingWith(x:T) = x.startsWith("abc")
doSomethingWith("abcdef")

The Scala interpreter makes very heavy use of reflection.

It's not a language construct, but ScalaTest includes Suite.execute, which uses reflection to find and invoke test methods.
Does Scala's pattern matching use any reflection behind the scenes?

Related

How to distinguish between a class and an interface in Kotlin using KClass reflection

I am using Kotlins KClass to find classes by name like this:
val i: KClass<*> = Class.forName("SampleClass").kotlin
However, I want to omit interfaces. So far I am distinguishing interfaces from classes by the constructor.
val i: KClass<*> = Class.forName(input).kotlin
if (i.constructors.isEmpty()){
println("This is an interface")
}else{
println("This is a class")
}
I don't think that it is very clean. I am looking for something along the lines of
i.isInterface
Does something like this exist?
Please note that the constructors counting solution might not be very precise for general purpose use. For example, Kotlin package facade classes do not have any constructors either, but they are not interfaces (UPD: and their constructors cannot even be reflected with kotlin-reflect, just as those of anonymous classes, KFunction and maybe more).
There's no function/property in kotlin-reflect that allows a straightforward check. On JVM, you can do it as i.java.isInterface or make an extension:
val KClass<*>.isInterface get() = java.isInterface

Assigning a parent to components or making the "object" the super?

As you've probably guessed, I had a hard time coming up with the Title.
Anyhow;
In Java, when adding X to a JFrame, X has access to the JFrame it has been added to, through the "super" keyword.
So basically
JFrame jf;
Component comp;
...
jf.add(comp);
Inside comp:
super.remove(this);
This code would add comp to jf and then comp would tell jf to remove itself from jf with the super and this keyword.
Is it somehow possible to get the super into C# code? Pointers, references???
The call
super.remove(this);
in Java means "call method remove() defined in the superclass, and pass this object as remove's parameter".
In C#, keyword base is used instead. Assuming that an identical method is defined in the base class, you call it like this:
base.Remove(this);
What Java calls a super class is called a base class in C#. The base keyword functions like the super keyword in Java, referencing the base class.
In Java, when adding X to a JFrame, X has access to the JFrame it has been added to, through the "super" keyword.
The way you describe it would not work in C# and I have my doubts about Java. The functionality you describe does not sound like inheritance at all. Are you sure your example would work in Java?

What are the uses of constructor reference in java 8

I was reading about Java 8 features, which lead me to this article and I was wondering about the actual uses of constructor reference, I mean why not just use new Obj ?
P.S, I tried googling, but I failed to find something meaningful, if someone has a code example, link or tut it will be great
First of all, you should understand that constructor references are just a special form of method references. The point about method references is that they do not invoke the referenced method but provide a way to define a function which will invoke the method when being evaluated.
The linked article’s examples might not look that useful but that’s the general problem of short self-contained example code. It’s just the same as with the “hello world” program. It’s not more useful than typing the text “hello world” directly into the console but it’s not meant to be anyway. It’s purpose is to demonstrate the programming language.
As assylias has shown, there are use cases involving already existing functional interfaces using the JFC API.
Regarding the usefulness of a custom functional interface that’ll be used together with a constructor reference, you have to think about the reason to use (functional) interface in general: abstraction.
Since the purpose of an interface is to abstract the underlying operation, the use cases are the places where you do not want to perform an unconditional new SomeType(…) operation.
So one example is the commonly known Factory pattern where you define an interface to construct an object and implementing the factory via constructor reference is only one option out of the infinite possibilities.
Another important point are all kinds of Generic methods where the possibility to construct instances of the type, that is not known due to type erasure, is needed. They can be implemented via a function which is passed as parameter and whether one of the existing functional interfaces fits or a custom one is needed simply depends on the required number and types of parameters.
It's useful when you need to provide a constructor as a supplier or a function. Examples:
List<String> filtered = stringList.stream()
.filter(s -> !s.isEmpty())
.collect(Collectors.toCollection(ArrayList::new)); //() -> new ArrayList<> ()
Map<String, BigDecimal> numbersMap = new HashMap<>();
numbersMap.computeIfAbsent("2", BigDecimal::new); // s -> new BigDecimal(s)
someStream.toArray(Object[]::new); // i -> new Object[i]
etc.

Microsoft Dynamics AX - java programist need information

I have to work with Dynamics 2012 r3 and x++ and I wonder:
what is "::" - its inherit, implementation or what?
why some variables are write like "_vensGroup" - that _ means something or this is just convention?
:: is a scope. It allows you to use class method (on tables and classes). The point is used to call an object method.
The scope is also used to call values on BaseEnum.
_ is a prefix for parameters. It's a convention. It allows you to recognize local variable and parameters. As parameters are not ment to be changed in a method (they are passed by value), you will always be able to distinguish it from local variables and use them in your code.
To answer both questions:
:: is a scope dereference to a (static) method (as opposed to . which dereferences a variable, constant or property), usually for the Global scope, but it could be for other similar scopes. It is reserved.
The underscore prefix is just a naming convention. It is not part of the language.
Regarding your underscore question:
A widely spread convention is to use leading underscores to indicate passed parameters e.g.
public void foobar(int _myInt, str _myStr)
{
...
}
See here for the best practice MSDN page describing this convention.
In addition to the other answers to your question, :: is used not only to call to static table/class methods, but for other purposes as well, e.g. call methods in maps or reference enums.

Why is object returned from getDefinitionByName()?

In Actionscript 3, why does getDefinitionByName() return an Object when the docs say:
Returns a reference to the class object of the class specified by the name parameter.
Based on that, I would conclude that the returned object should be Class instead of Object. Can someone enlighten me why that is not the case?
getDefinitionByName can also return a Function, such as getDefinitionByName('flash.utils.getDefinitionByName').
This only works on namespace-level functions, though, not static class methods.
Despite the method signature, getDefinitionByName does return Class. I think the misleading signature is due to the method existing before the Class object (when it used to return an anonymous/extended object instance).
Perhaps Adobe considered that this function might return different values in a future version of Flash Player. For instance, ECMAScript, the standard on which ActionScript is based, has historically used Function objects with prototypes as the basis for class-like objects. During discussions of the newest versions of the ECMAScript standard, there has been sugestions for "freezing" function-based classes at run-time to make them into something like compile-time Class objects. What if you could also specify a definition name for them? Are they actually of type Class at this point, or are they still or type Function? Probably the later, in my opinion. Both 'Class' and 'Function' references can be generalized as Object, so that return type makes sense in this context.
Note: This explanation is purely speculation based on what I've read in the ECMAScript specification wiki and the blogs of various committee members.

Resources