In most Dart documentation pages, some variables and functions are crossed out. like in https://api.dartlang.org/1.14.2/dart-js/dart-js-library.html
What does this signify?
In Dart metadata can be added to classes, fields, library declaratoins, parameters, ... as annotation.
#Deprecated('some reason')
class SomeClass {
String someField;
int otherField;
SomeClass({
this.someField,
#Deprecated('don\'t use this anymore") this.otherField});
}
is such an annotation and some tools like the Dart analyzer and dartdoc use this information to produce warnings (Analyzer) or other visual cues that some API still exists but should be avoided because it's planned to be removed eventually.
It signifies that the class, function, property etc. is deprecated
In Dart, annotations are used to mark something as deprecated. Notice the documented annotation on this class.
Related
I am very new to Kotlin development and I came across custom annotation classes in the documentation.
Is there a way for me to use an annotation on a function as a way to pre-populate some variables, or to run a decorator function before running the annotated function?
Something like:
class TestClass {
#Friendly("Hello World")
private fun testFun() {
greet()
//does something else
}
}
with an annotation class like
#Target(AnnotationTarget.FUNCTION)
#Retention(AnnotationRetention.BINARY)
annotation class Friendly(val message: String) {
fun greet() {
println(message)
}
}
I know this isn't valid Kotlin code, but I can't find any examples on how to actually use values from annotations without using reflection (if it's even possible)
Please let me know if I can do something like this, and more usefully, a better resource on annotation classes for Kotlin?
To make use of your custom annotations, you need to either create your own annotation processor (and use kapt Kotlin compiler plugin) to generate some new sources (but not modify existing!) at compile time, or use #Retention(AnnotationRetention.RUNTIME) meta-annotation (which is default in Kotlin), so that they could be accessed via reflection in runtime.
#Retention(AnnotationRetention.BINARY) meta-annotation you're using is equivalent of #Retention(RetentionPolicy.CLASS) in java, which is mostly useless (see https://stackoverflow.com/a/5971247/13968673).
What you're trying to do with annotations (call some additional code before/after method execution) reminds me aspect-oriented programming. Take a look at Spring AOP and AspectJ frameworks, following this paradigm, and their approach for annotations processing. TL;DR: Spring AOP is processing annotations in runtime, generating proxy-classes with respectful code, while AspectJ is using its own compiler (even not an annotation processor, cause it also introduces its own syntactic extension for java language), and can generate respectful bytecode at compile-time. They both are originally java-oriented, but with some configurational pain could be used with Kotlin too.
I noticed that some functions for coroutines are marked with actual keyword.
From documentation:
actual denotes a platform-specific implementation in multiplatform
projects
As I understood from documentation actual keyword is used for multiplatform projects and should work in pair with expect keyword.
Something like this:
Common module:
package org.jetbrains.foo
expect class Foo(bar: String) {
fun frob()
}
fun main(args: Array<String>) {
Foo("Hello").frob()
}
Corresponding module:
package org.jetbrains.foo
actual class Foo actual constructor(val bar: String) {
actual fun frob() {
println("Frobbing the $bar")
}
}
That case is clear.
But in package kotlinx.coroutines.experimental I noticed that some functions like launch or withContext are marked as actual but there are no expect functions in package.
So what is the purpose of actual keyword without expect?
The kotlinx.coroutines library actually makes use of multiplatform projects since it supports both the JVM and JS compilation targets.
You can find the common module here, and the specific expect declarations for the functions you've mentioned here.
While the source code in the other answer helped, I found this page (linked off of the page #jim-andreas mentioned in the comments above) was much more helpful.
Specifically, this passage:
If you're developing a multiplatform application that needs to access platform-specific APIs that implement the required functionality (for example, generating a UUID), use the Kotlin mechanism of expected and actual declarations.
With this mechanism, a common source set defines an expected
declaration, and platform source sets must provide the actual
declaration that corresponds to the expected declaration. This works
for most Kotlin declarations, such as functions, classes, interfaces,
enumerations, properties, and annotations.
The compiler ensures that every declaration marked with the expect keyword in the common module has the corresponding declarations marked with the actual keyword in all platform modules. The IDE provides tools that help you create the missing actual declarations.
Again, for more information, you can visit this page.
IDEA Community 2017.1.2, JRE 1.8, Kotlin 1.1.2-2
I have Java methods, located in libGdx that don't have any annotations regarding their nullability, e.g.:
public void render (final RenderableProvider renderableProvider) {
renderableProvider.getRenderables(renderables, renderablesPool);
as we can see, argument can't be null. However, since nothing tells that it's not-null argument, Kotlin will happily pass null in RenderableProvider?. How do I tell Kotlin to check during compile-time that I should be passing RenderableProvider and not RenderableProvider??
I've read about external annotations, however there is no "Specify Custom Kotlin Signature" and if I annotate renderableProvider as #NotNull nothing changes - kotlin still allows null.
I even tried to replace org.jetbrains.annotations.NotNull with javax.annotation.Nonnull in XML manually, but it makes no difference - code compiles and crashes with NPE.
External annotations are no longer supported. You'll either have to fork libgdx and annotate the methods there or live with this issue, unfortunately.
You could wrap it in an extension function and then only use that for rendering:
fun RenderClass.renderSafe(renderProvider: RenderableProvider) =
this.render(renderProvider)
Now you can't pass null.
I see kotlin.List and kotlin.MutableList is implemented by java.util.ArrayList. But where did kotlin put this trick? Compiler or somewhere in stdlib?
If kotlin supports making a class implementing an interface outside of its definition file like the ArrayList case, it will be fascinated.
No, it is not supported.
You are right, that is only a compiler trick. There are lots of magic applied to the collections to make them right. Fortunately it is not available to the devs. Special paragraph in the docs: https://kotlinlang.org/docs/reference/java-interop.html#mapped-types
Background
I'm wanting to follow the most commonly-practised naming conventions for TypeScript. I've noticed that the official website shows code examples featuring Pascal-case for types and modules and camel-case for just about everything else.
Example
I'm currently implementing a property that encapsulates a backing value:
class SomeClass {
get status() {
return statusBackingField;
}
set status(newValue: Status) {
statusBackingField = newValue;
//Do other work here
}
statusBackingField: Status;
}
Problem
The name of the property is status. In C#, I would normally name the property Status and the backing value status. Since the convention is to use camel-case for properties, this doesn't work. I'm not sure which convention I should use for consistency with other TypeScript code in general.
Question
Other languages, such as C# and Java, seem to have official or de facto standard conventions. Is there any such authoritative or de facto standard convention for naming backing fields in TypeScript?
Notes
For the close-voters: please note that I'm not looking for opinions. I'm looking for objective information as requested in the summarised question above.
There is no code convention standard for TypeScript. Since it is a superset of JavaScript, following JavaScript code conventions would probably be the correct approach. In such a case you would use an underscore-prefixed property _status. Idiomatically, this also matches the compiler’s use of an underscore-prefixed _this for compiled arrow functions and underscored-prefixed _super for superclasses.
In C# as well as TypeScript we use private _status. In C# the property will be Status. In TypeScript as you mentioned it is status
I think it's safe to say at this stage that there is no standard.
If someone can point me to an authoritative standard or evidence of a de-facto standard, then I may consider accepting their answer instead.