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).
Related
I have basic question about allocating memory for the value types.
If any value type is not used in the classes, functions or closures, how memory gets allocated for these value types lie struct or enums?
Also, I want to know, when ARC collects the objects for the value types. If they are not used in any reference types. After setting nil values to these value types, can we be sure that ARC picks up these objects?
Is int type in Dart a value type or reference type?
What is "reference type","value type","canonicalized" in Dart? (concrete definition)
I was looking into the specific definitions of "reference type" and "value type", but in the end, I thought it would be good to understand the code that represents the difference and the behavior (result) of that code.
If possible, I would like Dart code, but if it has the same structure as Dart regarding the above issues, there is no problem in other languages, so I would appreciate it if you could give me sample code.
The meaning of "reference type" and "value type" used here is the distinction made by C#.
A reference type is a traditional object-oriented object. It has identity which it preserves over time. You can have two objects with the same state, but they are different objects.
You don't store reference type values directly into variables. Instead you store a reference to them. When you access members of the object, you do so through the reference (x.foo means "evaluate x to a reference, then access the foo member of the object referenced by that reference).
When you check for identity, identical(a, b), you check whether two different references refer to the same object.
A value type does not have identity. It's defined entirely in terms of its state, its contents. When you assign a value type to a variable, you make a copy of it. It's the "value" in call-by-value.
C# allows you to declare value types with that behavior.
(Reference types do not correspond to call-by-reference, rather to call-by-sharing.)
In Dart, all objects are reference objects. This differs from, say, Java, where an int is a value-type ("primitive type" in their parlance), and they have a separate Integer class which can wrap the int values and is a reference type. That's needed because Integer is a subtype of Object, but int isn't, so you can't store int values in a generic container which expects a subtype of Object.
In Dart, some reference types are still more value-like than others. In particular numbers.
A Dart number, like the integer 1, has precisely one object representing that value. If you write 1 in different places of the program, or even calculate 4 ~/ 4 or 3 - 2, you always get the same object representing the value 1. It's like it's not an object at all, and identical only compares values. And that's precisely what happens, because it allows the compiler to treat integers as primitive values internally, and not worry about sometimes having to give you the same 1 object back that you put in.
This is sometimes expressed as integers being "canonicalized": There is only one canonical instance representing each state.
Dart also canonicalizes other objects.
Constant expressions are canonicalized, so that two different constant expressions generating instances of the same type, with identical states, are made to return the same, canonical, instance representing that value.
Since the value is guaranteed to be immutable, there is no need to have equal objects with different identities. (If they were mutable, it matters very much which one you mutate and which one you don't).
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
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.
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.