According to the source of Kotlin's lexer, there is a typealias keyword, and it's not "reserved for future use" like yield and typeof.
Also, the grammar reference suggests that typealias should be a valid keyword for a class member declaration, and when I type typealias in IntelliJ IDEA (Android Studio) with Kotlin plugin it recognizes it as a keyword but I get expecting member declaration error. I have also tried using it with the "usual" syntax, for example like it is implemented in Swift, however with no success.
So, is the typealias feature actually implemented in Kotlin (as of 1.0), and if so, what is the syntax for it? Is there any documentation that describes its use?
Update
Kotlin 1.1 supporting type aliases is now out!
With a typealias, you can provide an alternative name for an existing type since Kotlin 1.1:
typealias Multimap<K, V> = MutableMap<K, MutableList<V>>
For more information, see the official documentation or the KEEP proposal.
Related
Should I give type when creating variable?
Any downside for just declaring the keyword "var"?
Any difference between these two?
var a ＝ 0;
int a ＝ 0;
Pros/Cons
ONGOING WORK
Best Practices
It's recommended to use var or final keyword, without specifying type annotation, and implicitly infer type for known local variables. Otherwise it's recommended to specify type annotations. As for dynamic keyword, it should be used very sparingly in specific use-cases, when you're doing manual type checking. For example print(myVariable is SomeType).
omit_local_variable_types Dart linter rule encourages omitting type annotation for known local variables. always_specify_types encourages specifying type annotations for cases that don't fall into the scope of the former linter rule.
1. Style guide for Flutter repo
1.1 avoid using var
All variables and arguments are typed; avoid "dynamic" or "Object" in
any case where you could figure out the actual type. Always specialize
generic types where possible. Explicitly type all list and map
literals.
This achieves two purposes: it verifies that the type that the
compiler would infer matches the type you expect, and it makes the
code self-documenting in the case where the type is not obvious (e.g.
when calling anything other than a constructor).
Always avoid "var". Use "dynamic" if you are being explicit that the
type is unknown, but prefer "Object" and casting, as using dynamic
disables all static checking.
2. Dart Lint Rules
2.1 omit_local_variable_types
CONSIDER omitting type annotations for local variables.
Usually, the types of local variables can be easily inferred, so it
isn't necessary to annotate them.
2.2 always_specify_types
DO specify type annotations.
Avoid var when specifying that a type is unknown and short-hands that
elide type annotations. Use dynamic if you are being explicit that the
type is unknown. Use Object if you are being explicit that you want an
object that implements == and hashCode.
References
You can refer to Style guide for Flutter repo, full list of Dart's Linter Supported Lint Rules, and Effective Dart's Style Guide.
Note, Style guide for Flutter repo is used among flutter community and takes precedence over LinterRules and Effective Dart's Style Guide especially within repo contributions. From what I've seen, Style guide for Flutter repo is more of a superset Style Guide that should honor Dart Linter rules.
There isn't any difference between the two statements you gave.
And I don't see any downside to only declare the keyword "var", unless that your code might become a bit more difficult to read. On the other side, specifying the type might become a bit redundant sometimes.
But this is really just a question of taste 😄
I advise you to pick between those two, and be consistent in your code.
If you choose to always specify the type, you can use always_specify_types in your file analysis_options.yaml :
https://dart-lang.github.io/linter/lints/always_specify_types.html
Why TypeProvider supports static parameters, how is this done, and does the f# compiler specifically support this feature?
I write a class myself, do not implement the ITypeProvider interface, can do the same effect?
The syntax of static parameters is not described in the f# language reference, is there any relevant help?
Thank you very much!
I think you are asking if the static parameters mechanism used in type providers can be used in ordinary F# code.
The short answer is no.
Type providers are special: they are compiler plug-ins that provides types, properties, and methods for use in your code. Special rules apply to them.
I am trying to implement a delegate for an NSWebView, however when I run it, I get this error:
TypeError: Error when calling the metaclass bases
class Delegate does not correctly implement protocol WebScripting: the signature for method isSelectorExcludedFromWebScript: is c#:: instead of Z#::
Where can I find documentation for 'c#::', as opposed to 'Z#::', and what might be wrong with my code?
The method in question is as follows:
def isSelectorExcludedFromWebScript_(self, sel):
return True
Specifically, the NSWebView is documented at: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/WebKit/Classes/WebView_Class/index.html (But I suspect that Apple will move this URL in future)
More precisely, the delegate's informal protocol I am attempting to use is documented here: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/WebKit/Protocols/WebFrameLoadDelegate_Protocol/index.html#//apple_ref/doc/uid/TP40003828 and https://developer.apple.com/library/mac/documentation/Cocoa/Reference/WebKit/Protocols/WebScripting_Protocol/index.html#//apple_ref/doc/uid/TP40001562
The only documentation for objc.signature I have found is at: http://pythonhosted.org/pyobjc/api/module-objc.html
The standard objective-c type encodings are documented in Apple's ObjC runtime reference. This defines c as char, # as object, and : as selector, but doesn't mention Z.
PyObjc adds a few that aren't on that list, described in http://pythonhosted.org/pyobjc/api/module-objc.html#objective-c-type-strings by reference to a bunch of constants in the objc module. objc._C_NSBOOL has the value Z (also mentioned in the pyobjc BridgeSupport docs)
So it looks like the problem has to do with the conversion of Python's True to the correct objective c type, but I'm not sure how to correct the problem.
What exactly is the difference between F#'s type augmentation and type extension, and do we really need both?
Are there situations where one is better than the other, and vice-versa?
I'm asking because I recently had a lecture in F# where the lecturer talked about both, and afterwards commented that he couldn't see the reason why both were included in the F# language.
Update:
Ok, so Vladislav Zorov links to a page with examples of using type augmentation both when defining your own types, and extending (or augmenting?) an external type.
pad links to an MSDN page where they call it intrinsic and optional type extension.
Both seem to illustrate the same thing. Can someone come with a concrete example of type extension and another concrete example of type augmentation perhaps, in order to explicitly clarify what the two things are exactly?
The following bits from MSDN's Type Extensions page are relevant (emphasis mine):
There are two forms of type extensions that have slightly different
syntax and behavior. An intrinsic extension is an extension that
appears in the same namespace or module, in the same source file, and
in the same assembly (DLL or executable file) as the type being
extended. An optional extension is an extension that appears outside
the original module, namespace, or assembly of the type being
extended. Intrinsic extensions appear on the type when the type is
examined by reflection, but optional extensions do not. Optional
extensions must be in modules, and they are only in scope when the
module that contains the extension is open.
The purpose of optional extension is clear. It helps you inject new functionalities to types not belonging to your assemblies. For examples, FSharpx uses it to create various helpers for parsing primitive types:
open System
type Boolean with
static member parse x =
match bool.TryParse(x) with
| true,v -> Some v
| _ -> None
Why do you need intrinsic extension then? The answer is its convenience. I find it useful to break down type definitions to multiple sections with clear purposes.
In many F# libraries, I saw the use of the following pattern: type definition -> utility functions -> intrinsic extension. In this way, you can define sophisticated utility functions on your types, make them available in modules and still can use them directly in your member definitions. You can look at Complex type in F# PowerPack to see the pattern.
EDIT:
To be honest, I often use type extension and type augmentation interchangeably. The thing that matters is whether they are intrinsic or optional.
They are different things. Type augmentations, when defined in the same namespace, module and source file, actually become part of the type when compiled. Type extensions (a.k.a. type augmentations for types outside of the module and source file) are implemented with .NET extension methods.
They both use the same syntax, the only difference is whether the type you mention is in the same namespace and assembly, i.e. you're augmenting your own code and the additional methods can be added to your type before compilation.
Source: http://tomasp.net/blog/fsharp-iii-oop.aspx
Edit:
This is a terminology mix-up, they are both referring to the same thing - intrinsic extensions are type augmentations of the first kind (i.e. same namespace and assembly), optional extensions are type augmentations of the second kind (i.e. 3rd party assembly, in the blog post this is the List<T> augmentation example).
I assume when your lecturer is talking about type augmentations, he's referring to intrinsic extensions, i.e. first kind type augmentations, and when he's talking about type extensions, he's talking about optional extensions, or second kind type augmentations.
If one uses the F# Interactive Shell (FSI), the inferred expression type (signature) is printed to the console along with its value:
val it : int * string * float = (42, "Hello F#", 42.0)
How can I mimick the same behaviour in my own code, e.g. to get the inferred types as string for a F# expression?
I don't need to dynamically evaluate any F# expressions, the expressions are known in compile time and are part of my (static) F# code. I need this feature to be able to mimick the FSI output in LINQPad for my F# demos.
Using Unquote
Unquote has a facility for getting the F# signature of a type. Simply download the latest release and add a reference through LINQPad to Unquote.dll, then you can do e.g.
If you're interested, you can peak at the source code for the implementation of the FSharpName Type extension: https://github.com/SwensenSoftware/unquote/blob/2.1.0/Unquote/ExtraReflection.fs#L54
Using FsEye
Another neat approach would be to use LINQPad's beta Custom Visualizer API to embed FsEye into LINQPad (FsEye uses the same F# type signature printing algorithm as Unquote). This is also very simple, all you need to do is download LINQPad beta, download and reference FsEye.dll from the latest release of FsEye, then you can do e.g.
If you look at the F# compiler code and see how the --sig option is handled by the compiler I think that will get you what you're looking for. More about the --sig option and signatures here:
Signatures (F#)