Why in dart we have String not string
Other types are in lower case
int not Int
double not Double
The reason for the naming was to make Dart more familiar to people coming from Java (or C#, but mostly Java).
That's why int, double, bool and void are lower-case and String is capitalized, because that's what they were in Java (although boolean was considered too damn long).
The num type got looped in too, because it's so closely tied to int and double, and dynamic was lower case to mark it as a special type, like void.
(Special types added later, like FutureOr or Never, were not made lower case because that increased the risk of conflicting with existing variable names, something the original language didn't have to worry about.)
Dart does not have primitive types like, say, Java. All Dart values are objects, and you can call methods on them.
Primitive types are starting with lower case (int, double, char ...). String is not a primitive type its an object therefore it doesn't start with lower case
Related
My question is short and simple.
when everything is in dart no matter it is a string, boolean, int, float, or char everything is stored in the object in dart language.
so according to the definition anything which has a reference type(Stored in object) is non-primitive, so is all the above types are non-primitive in the dart, or if these are primitive then what about the definition, anything stored in an object is non-primitive.
also, tell me what are the primitive data types of dart language
If you define "primitive value" to be a non-reference value, Dart doesn't have any.
All Dart values are (references to) object instances that implement either Object or Null. All can be stored in a variable of type Object?.
Some types are more closely supported by the runtime system (like int, double, String, bool and Null), and for performance and platform interoperability reasons, you are not allowed to have your own classes implementing those. In a sense, those are "fundamental" types (I wouldn't say "primitive", but others might).
Let's say I have a function foo which takes two arguments:
actual fun foo(list1: List<Long>, list2: List<Double>) {
...
}
According to the https://kotlinlang.org/docs/tutorials/native/apple-framework.html Kotlin's Long type is mapped to KotlinLong and Kotlin's Double is mapped to KotlinDouble. Now I would like to call this function from my iOS App. Let's say I have two arrays:
let list1Numbers = [1000.43, 564121.34, 5617172172.234, 100.7]
let list2Numbers = [2.1, 3.2, 1.7]
For the list2 I could do something like:
let list2NumbersKotlin = list2Numbers.map({KotlinDouble.init(double: $0)})
which is not very convenient but will work. The list1 is a bit more problematic. Since there is no Long in Swift, I do something like
let list1NumbersKotlin = list1Numbers.map({KotlinLong.init(longLong: Int64($0))})
Questions:
Is there a better way to do it ?
What is a typical approach to deal with such types mapping when using Kotlin as an iOS Framework ? Unfortunately I couldn't find any examples on the Internet.
Should certain types such as Long be completely avoided if I want to use Kotlin as iOS Framework ?
Also, regarding mapping in general: since the Kotlin function
fun testDouble(testVal: Double) {}
allows me to pass in Swift the Double directly:
HelloKt.testDouble(testVal: Double)
then why does the function
fun testList(testList: List<Double>) {}
not allow me to enter Double array but requires a KotlinDouble array ?
HelloKt.testList(testList: [KotlinDouble]){}
Passing a [Double] gives error:
Cannot convert value of type '[Double]' to expected argument type
'[KotlinDouble]'
There are multiple ways.
You are talking about collections of data that are on the line between primitive types and objects, which tends to be a special case in Kotlin anyway.
Speaking to that, in Kotlin, you might want a LongArray and a DoubleArray rather than List<Long> and List<Double>. Coming from Swift, you'll be forced to explicitly box them. Kotlin will handle that for you when you're writing Kotlin code, but they're still getting boxed under the hood.
So, summary, either what you've done above, or take LongArray and DoubleArray as args rather than lists, and do a different translation. Either way, you will need to move the data into something Koltin compatible.
Obviously, if you put that in a helper function, ugly as it perhaps may be, you only need to do it once.
Either your method or what I described.
Long isn't problematic. There is a "long" in Swift, it's Int64. Having to wrap values like that isn't fun, but Kotlin and Swift are different languages, and there are compromises. If you use Int in Kotlin instead of Long, you'll need to wrap a Swift Int with Int32. A Kotlin Int is, in that sense, "problematic" in the same way. You need to specify which precision int you're using.
In Kotlin, List<Long> is a list of Long objects, while just a Long is a primitive value. Kotlin hides the boxing of those values, but they are boxed. The Swift/Kotlin interface is forcing you to be more explicit. If you want primitive values, use the ___Array forms mentioned above.
Is it Java ancestry or is it collection related?
Is there a pattern and how dynamic type fits in it?
Dart chose the naming for its familiarity for people coming from Java. That's why int, double, void and bool are lower-case even though they are not "primitive" types in Dart (and even if bool was made shorter than the Java boolean type.)
The num class does not exist in Java, but it follows int and double types for consistency.
The dynamic type was probably just lower-cased for convenience, and because it was actually a non-class type.
Historically languages like Java and C# have categorized the types into 2 main categories:
primitive types (int, char, bool, long, double etc)
user-defined types (List, Map, Future, Animal, Car etc)
To set the difference clearly, the convention has been to follow CamelCase i.e. starting with a capitalized character for user-defined types and follow pascalCase for primitive ones
dart, like lot of other features takes this convention from these 2 languages.
NOTE: The String type has been a special case for a long time. C# has both a type named string and an alias type named String. Java however takes the C++ philosophy and doesn't consider String as a primitive type. Hence uses CamelCase. For String dart has followed the java path.
PS This GitHub Issue discusses about the String issue in detail.
F# has multiple ways to declare the same types. This is likely because of the dual lineage of F# as both a member of the ML family and a .NET language. I haven't been able to find any guidance on which style is more idiomatic.
Specifically, I want to know:
Which is more idiomatic for 64-bit IEEE 754 floating-point numbers in F#, float or double?
Which is a more idiomatic way in F# to declare an array type:
int[]
int array
array<int>
Sources:
https://learn.microsoft.com/dotnet/fsharp/language-reference/basic-types
https://learn.microsoft.com/dotnet/fsharp/language-reference/fsharp-types#syntax-for-types
Context: I'm working on some API documentation that is explaining how data in a data store maps to .NET types, along with how those types are typically declared in both C# and F#.
For doubles, it's pretty much always float. Unless you deal with both singles and doubles and need to ensure clarity I guess.
For generic types, the usual syntax I use and see people use is:
int option
int list
int[]
For all other types, including F#-specific ones like Async, Set, and Map, angle bracket syntax is used.
The only type that I feel has a significant split is seq (an alias for IEnumerable): I'd say the majority of people use seq<int> but a significant number of people write int seq. Either way, you should definitely use seq and not IEnumerable. Similarly, you should use the alias ResizeArray for System.Collections.Generic.List.
The F# Core Library reference, which seems like a good example to follow, seems to prefer float, int[] and seq<int>.
In F#, is there a special name for a type defined in the following manner:
type Foo = int -> string
I ask because such a type seems to have special significance. It is quite abstract compared to other types and seems to only be usable as a sort of function interface. It is not discussed much in F# literature, but it is used quite a bit in the source of many F# OSS projects.
Is it a special sort of type that has some broader significance in functional programming? Does it have other applications other than functioning as a sort of interface for functions? Why is it something that doesn't really make sense to instantiate, even though you can kind of do that by defining a function with a matching type signature? Or is it really just as simple as saying that it is an alias for a function definition which can then be used as a short form in other type signatures/definitions and that accounts for all it's properties?
The name used in the F# documentation for this kind of definition is type abbreviation and I think many people often refer to it as type alias.
The definition defines an alias or a shorter name for a longer type. It says that whenever you type Foo, the compiler will see it as int -> string.
Type abbreviations do not define a new type, which means that Foo and int -> string are equivalent (a value of one type is also a value of the other type). The important points are:
Type inference will generally infer the original type, so when you write a function that matches the type, compiler will infer it as int -> string unless you give an explicit type annotation
When compiled, the abbreviations are erased (because .NET does not have such concept) and so the compiled code will see int -> string.
Abbreviations are useful just for readability reasons - it lets you use more descriptive name for a type. However, they do not have many other implications.