Can anyone explain the (of Out T) component to this interface? I'm familar enough with how interfaces work. I also understand that T refers to a type... Whats going on with the Out portion.
Public Interface IPageOfItems(Of Out T)
Inherits IEnumerable(Of T)
Property PageNumber() As Integer
Property PageSize() As Integer
Property TotalItemCount() As Integer
ReadOnly Property TotalPageCount() As Integer
ReadOnly Property StartPosition() As Integer
ReadOnly Property EndPosition() As Integer
End Interface
.NET 4.0 introduced covariance and contravariance of generic types. Here's what this means.
Covariance
The Out keyword here indicates that the type is covariant. A covariant type T(Of D) can be cast to a type T(Of B) where D derives from B. This is possible when the type T(Of D) only ever uses D values as output (hence the word Out).
For example, the IEnumerable(Of Out T) interface is covariant because none of its methods accepts any parameters of type T. Therefore, an IEnumerable(Of String) can be cast as an IEnumerable(Of Object) -- if it provides enumerable access to strings, then it provides enumerable access to objects (since strings are objects).
Contravariance
Conversely, the In keyword may be applied to a type that is eligible for contravariance. A contravariant type T(Of B) can be cast to a type T(Of D) where D derives from B. This is possible when the type T(Of B) only uses B values as input (hence the word In). In other words, contravariance is the exact opposite of covariance.
A good example of a contravariant type would be the IComparer(Of In T) interface. This interface provides no methods that return T values; therefore an IComparer(Of Object) could be cast as an IComparer(Of String) -- after all, if it can compare objects, it can compare strings.
This is new .NET 4 feature that allows you to specify variance with generic arguments. Pretty much everything you need to know:
http://msdn.microsoft.com/en-us/library/dd799517.aspx
This is to indicate the interface is covariant in generic parameter T. Check Generic Variance heading in this article that explains new features in VB.NET 2010 (.NET Fx 4.0).
In short covariance will allow to substitute smaller type (such as subclass) instead of larger type. For example, if Tiger is inherited from Animal then we can use IEnumerable(Of Tiger) in place of IEnumerable (Of Animal). Eric Lippert has explained variance (in context C#) very well in series of blog posts.
Related
I'm trying to learn F# by converting an existing .NET Core solution in C# over, one project at a time. I currently have an interface in C# with nullable reference types:
public interface IVehicle {
public int GetWheels();
public string? GetLicensePlate();
}
And this interface is implemented in a number of other projects which depend on this one. I'm trying to convert one of these over, but if I try
type Car(serialNumber: string) =
interface MyProjectInterfaces.IVehicle with
member this.GetWheels() = 4
member this.GetLicensePlate() =
match LicensePlateService.GetLicencePlate(serialNumber) with
| Some(x) -> System.Nullable(x)
| None -> System.Nullable()
I get the error:
This expression was expected to have type 'string' but here has type 'Nullable<string>'
This doesn't seem to affect value types, so I'm assuming it's something to do with string being a reference type.
What do I do to solve this? Presumably I could rewrite the underlying interface to use F# and thus options, but there are other C# projects that implement the interface and I don't want to have to rewrite the whole solution in one go. Or am I doing F# completely wrong?
This is a confusion between C# 8's nullable references and nullable value types, aka Nullable<T>. If you look at the definition of Nullable<T>, you'll find:
public struct Nullable<T> where T : struct
which means it's only for value types. int? is short for Nullable<int>.
That's different from nullable references.
The nullability modifier for reference types doesn’t introduce a new type. Reference types are still nullable and compiling string? results in IL that’s still just System.String.
The difference at the IL level is the decoration of nullable modified types with a NullableAttribute.
In other words, it's just a compiler construct - one which isn't visible to F#.
match LicensePlateService.GetLicencePlate(serialNumber) with
| Some(x) -> x
| None -> null
will be the correct, albeit non-idiomatic replacement.
In this question about the passing of arguments in JavaScript functions, we learn that everything is passed by value in JavaScript.
In Mozilla documents, it is mentioned that the primitive types are immutable, and objects are. Although I came from the procedural and structured programming school, I was able to quickly pick up the concepts.
In the ECMAScript standard, it is defined that "An Object is 'logically' a collection of properties". The standard also defines how objects may be compared, but left out on what happens when an object goes through the GetValue() pseudo-function that converts references into values.
So, I gave an answer in the question basically saying that this area had been left undefined.
My Question
I feel that by "left undefined", I meant, it wasn't philosophically thoroughly clear, what the value of an Object is. The standard had gone through a few revisions, and its size is ever increasing.
In short, an object is a collection, but what is the value of the collection? Is it the makeup of its content? Or is it individuality? Or have I been missing out on some important texts?
In the ECMAScript spec, every object is defined to have certain 'internal methods', some of which (e.g., [[DefineOwnProperty]] and [[Put]]) can change the state of the object. Ultimately, the mutability of objects is defined via the use of such internal methods.
GetValue() doesn't leave out what happens to objects -- step #1 is:
If Type(V) is not Reference, return V.
So it you pass it an object, you get back the same object.
(Which refutes one of your premises, but I'm not sure it resolves your question.)
See section 4.3.26 "property" of the 5.1 edition. The note says:
Depending upon the form of the property the value may be represented either directly as a data value (a primitive value, an object, or a function object) or indirectly by a pair of accessor functions.
We can take this as meaning a data value is one of the following:
Primitive Value: such as C language double, _Bool, ((void*)0), etc.
An object: which can be interpreted as a special C language structure containing the underlaying information about the object.
Function object: which is just a special case of 2, possibly the result of JIT compilation.
The reason this note for the definition of property is important, is because, everything - even function block scopes - are objects (or at least described in terms of one). Therefore, if we can determine that "the value of an object" is its individuality rather than its content makeup, then with the fact that every object accessible from a JavaScript program, is accessed as if its the property of some other object.
In section 4.2 "Language Overview", it says:
A primitive value is a member of one of the following built-in types: Undefined, Null, Boolean, Number, and String; an object is a member of the remaining built-in type Object; and a function is a callable object.
Although this is an informal section, it can be seen that an object differs from a primitive value in a significant way.
As an interpretation, let's consider the value of an object is the object itself as we can infer from the "GetValue()" pseudo function - the overview says "an object is a member of the ... type Object - therefore, the value is the membership to the Object type.
To use a physics analogy to explain the relationship between membership and individuality, we see too electrons. They are identical in content, they're both the members of the Universe, yet they are two different individuals.
Therefore, we infer that - the value of a JavaScript Object, is its individuality.
Finally as to the question as asked in the title.
The mutibility of individual objects is defined in terms of a series of specificational pseudo functions, and immutability of other types is defined using the definition of value membership of types and specification pseudo functions operating on the primitive type values.
I wrote the below code to get a KClass of Array<*>.
Array::class
However, this code has a compilation error.
Kotlin: Array class literal requires a type argument, please specify one in angle brackets
Do you know the reason or solution?
On the JVM platform, Kotlin Array<T> types are mapped to Java arrays, which, unlike Java generic types, are not subject to type erasure, they are reified instead.
It means, among other things, that arrays with different element types are represented by different classes, which have different Class<T> tokens, and these class tokens contain the information about the element type as well. There's no generic array type, but only array types for arrays with different element types.
Since generic Array<T> doesn't exist, you cannot use its reflection either, you can only get the runtime type information of array types with specified element types:
val c = Array<Int>::class // corresponds to Java Integer[] type
val d = Array<Array<String>>::class // corresponds to Java String[][]
val e = IntArray::class // corresponds to Java int[]
If you need to check whether an arbitrary class is an array type, you can do it with Java reflection:
val c = Array<Int>::class
println(c.java.isArray) // true
I'm having some difficulties getting my head around inheritance in Ada, and with some syntax.
My goal is to derive from an abstract type with a record, and use a different data type in the record field. Here's what I've been able to compile:
type Base is abstract new Parent.ParentType with record
X:Access_Type;
end record
type Child is new Base with record
n:Integer;
end record;
But I don't want to have this additional n field, I'd like to have X be an integer in the child type. I can't get the compiler to be happy with it. Something like the following is what I want:
type Base is abstract new Parent.ParentType with tagged record
X:Access_Type;
end record;
type Child is new Base with record
X:Integer;
end record;
Unfortunately, I can't figure out how to tag the base type which I think would allow me to reassign the X field. (Without tagging, the compiler complains of conflicting declarations.)
Can someone shed some light on this? I'm quite new to OO programming in general and I'm finding Ada's type approach more confusing than the usual class approach.
Are you sure you are not just wanting to nest some records ?
type Base is abstract new Parent.Parent_Type with record
X : Float;
end record;
...
type child_rec is
X : integer;
end record;
...
type Child is new Bases.Base with record
C : Child_Rec;
end record;
Which will allow you to refer to
My_Base.X;
and
My_Base.C.X;
Of course this can be done without any of the OO features too....
I'm not sure what problem you are trying to solve by changing the type of X in a derived type. As suggested in Ada 95 Rationale: II.1 Programming by Extension, extension of a tagged type adds components to those inherited from the base type. You may be looking for a way to specify parameters for a derived type using discriminants.
Addendum: It may help to understand that Ada's support for common object-oriented programming principles is not limited to tagged types.
The Ada Programming Language: Object-Oriented Programming (OOP) outlines the historical perspective. Prior to the advent of tagged types, Ada was considered object-based, with strong support for data abstraction, encapsulation, messaging, modularity, and inheritance; tagged types expanded the support for polymorphism, and later additions refined the feature.
A Comparison of the Object-Oriented Features of Ada 95 and Java offers a detailed comparison with a (possibly) more familiar language.
Base has to be tagged, because you can't say is abstract new Parent.Parent_Type unless Parent.Parent_Type is tagged, and that means that any derived type such as Base must be too.
The problem is that, as you have it, any code that can see Child could see two Xs; the one in Base and the one in Child. The compiler won't let you be ambiguous; when others read your code and see My_Child.X, how will they know which X you meant?
One way round this would be to make the full declaration of Base private, so that there's only one visible possibility for My_Child.X:
package Bases is
type Base is abstract new Parent.Parent_Type with private;
private
type Base is abstract new Parent.Parent_Type with record
X : Float;
end record;
end Bases;
with Bases;
package Children is
type Child is new Bases.Base with record
X : Integer;
end record;
end Children;
I think i am lost with basics itself. What is the difference between these two. String object is an instance of String Class.
var guru:Object = new Object();
var guru:String = new String();
An object is a basic object. It has very few intrinsic properties and methods. More detail here
A string is an extended object that has the properties and methods relevant to strings. More detail here
If you're really not sure, I'd suggest looking up the answer here:
http://livedocs.adobe.com/flex/3/html/help.html?content=03_Language_and_Syntax_11.html
Briefly, it states:
String data type
The String data type represents a
sequence of 16-bit characters. Strings
are stored internally as Unicode
characters, using the UTF-16 format.
Strings are immutable values, just as
they are in the Java programming
language. An operation on a String
value returns a new instance of the
string. The default value for a
variable declared with the String data
type is null. The value null is not
the same as the empty string (""),
even though they both represent the
absence of any characters.
Object data type
The Object data type is defined by the
Object class. The Object class serves
as the base class for all class
definitions in ActionScript. The
ActionScript 3.0 version of the Object
data type differs from that of
previous versions in three ways.
First, the Object data type is no
longer the default data type assigned
to variables with no type annotation.
Second, the Object data type no longer
includes the value undefined, which
used to be the default value of Object
instances. Third, in ActionScript 3.0,
the default value for instances of the
Object class is null.
If that doesn't satisfy your question, you're going to have to get more specific.
This guide can help you with basic Object Oriented questions regarding ActionScript 3.
The reference guide for String states that String inherits directly from Object.
The String class provides a bunch of useful methods that help with string manipulation on top of the few methods that Object provides (like toString()).