I have dynamic item attributes in a dictionary that could hold either a single or a string or 2 other custom classes.
Right now i store the value in a class that has uninitialized variables for all of these and another variable to say which type to get upon request. I don't like it because it's rather clunky and seems to waste memory (since most of the time the value stored is a single).
I figured i could hold any of these in a single object variable type but i don't know what kind of penalties to expect from this, if any. Should i continue with managing the types myself or let vb figure it out?
The main thing you should worry about with the Object type in VB.NET is late-binding. If you call a method on an Object variable (except for those methods that are part of the Object type, such as ToString), the vb runtime has to use reflection to find and call the correct methods on the exact type when they're executed. If you use a specific type for your variable, that lookup will only occur once, when your code is JIT-compiled. I would say that the overhead of late-binding is significant enough that you should avoid it when possible.
However, that doesn't apply to checking the object's type and assigning to a variable with a more specific type. So if you figure out what type of object you have and assign it to the right type of variable before calling methods on it, you should be ok. There is a little bit of overhead to doing that, but it's probably no worse than what you're already doing.
Another reason to avoid late-binding is that it prevents the compiler from doing type checking.
Related
I want to start with what I know, or at least I think I know, so what I'm asking would be more clear.
First of all, I know that you can declare a variable of a supertype and assign an object of a subtype to take advantage of polymorphism with Inheritence and Interfaces.
I know that generics provide type safety because the type parameters are invariant by definition, so where A is a subtype of B, Foo<A> is not necessarily a subtype of Foo<B>, and may not be used in place depending on mutability of the object. With this, possible exceptions that could arise at runtime due to dynamic dispatching can be caught in compile time.
They also help to define a generic logic for different types: Like in Lists where you have collections of type A objects, but it doesn't change the implementation for type B objects.
Also, I understood why MutableList<String> doesn't count as the subtype of MutableList<Any> because that could result in cases where you create a variable with type MutableList<Any> that holds a reference to a MutableList<String> object, and add an Int element to a List of Strings, which is obviously a problem.
I also understood why List version of the previous example works because Lists are immutable so you can't make any modification to the object that could result in type mismatches.
Lastly, I know that type parameters with in can only be used as function parameters, being consumed, and the ones with out can be used as the function return types, being produced.
Now to the part what I don't understand:
I didn't quite understand what the words consumer and producer actually means in terms of in and out. What does it mean for a type to be in consumed or produced position? Does that mean the object with that type can only be read or write only? Does that have anything to do with the object at all?
What would be the behaviour of the object if, let's say, we don't define it using in or out, or, opposite, we define it using in or out, not talking about the subtype-supertype relationship that I explained above.
I spend the last few days looking at different explanations of this, but I found the lack of examples a big problem, especially because that's how I usually learn.
I can use these concepts in code, but the lack of underlying knowledge or the logic greatly disturbs me, so please, if you decide to take the time to write an explanation, provide it with examples and counter examples of why or how a certain idea works.
Just one correction to your first bullet points: List is not immutable; it is read-only. A List could be an up-cast mutable implementation and some other object that references it could be mutating it.
Producer means the generic type appears as a return type in any functions or properties of the object. You can get T’s out of a List, for instance.
Consumer means the generic type appears as a parameter of any functions or as the type of any var properties of the object. You can put T’s into a MutableList, for example.
Since List produces but doesn’t consume (it doesn’t have any functions with T as a parameter), its type is marked as producing-only, aka covariant, aka out right at the declaration site so its type can always be assumed to be out wherever it’s used even if the out keyword is not used.
Since the List type is always covariant out, any List can be safely upcast to a List where the type is a supertype of the originating type. A List<String> can be cast to List<CharSequence> because any item you get out of it (anything it produces) is going to be a String, and therefore also qualifies as the supertype CharSequence.
The reverse logic would apply for something that is purely a consumer with the type marked in, but it’s harder to come up with a simple example where you would actually have a useful object like this.
A MutableList both produces and consumes, so it is invariant by default, but since it is also a List, a MutableList<String> could be safely cast to a List<CharSequence>. If you have a reference to the List<CharSequence>, you can get CharSequences out of it. The underlying object might continue to have new Strings put into it from the original reference.
is there any type of Object in abap, so that I can save any kind of data in it?
the reason is the following:
I'm writing some code and I dont know what kind of data I will get back. If I would work with java I would save it in a Object.
Is there something equal in ABAP?
If you are looking for data types, there is a generic type named DATA. For objects (instances), a similar type named OBJECT exists. The generic type ANY will contain either one of these, but it's rather pointless to use it for both objects and values at the same time, because you'll end up handling data with references which can be really error prone (and is not something you should attempt to do if you don't know about generic types in the first place).
Using c++ CLI, is it recommended not to use tracking handle for value class?
for example
value class Point {
};
Point p;
or Point ^p;
C++/CLI permits that syntax, unfortunately, it cannot be expressed directly in other managed languages. You end up with the value getting boxed in an object and stored on the GC heap. Every assignment will box, reading the value unboxes it again. That's quite expensive and 99.9% of the time is the wrong thing to do. The point of value types is to make your code fast, avoiding the extra indirection through an object reference and taking advantage of processor registers. A value type value like Point fits in two registers.
By declaring it as a handle, you get the disadvantage of a ref class but add the expense of having to unbox the value every time you retrieve a member of the value type. It therefore makes no sense to do this at all, if you need a Point class with reference type semantics then just declare a ref class Point and entirely avoid the un/boxing cost. C++/CLI has a few design flaws, induced by trying make it match native C++ semantics. This is one of them.
So no, this is not recommended.
In object oriented programming languages when you define a variable it ends up becoming a reference to an object. The variable is not itself the object, and instead points to the object that carries the value that was assigned to that variable.
Question is how does this work so efficiently? What is the mechanism of how a variable is assigned to an object?
The way I think about the organization is as a linked list, however could not find references how the data is structured in languages such as Ruby or Java.
In object oriented programming languages when you define a variable it ends up becoming a reference to an object.
This is not always true. For example, C++ can be considered an object-oriented language, yet a user of the language can use a variable as a reference/pointer or explicitly as a value.
However, you are right in that some (typically higher-level) OO languages implicitly use references so that the user of the language does not have to worry about these kinds of implementation "details" in regards to performance. They try to take responsibility for this instead.
how does this work so efficiently? What is the mechanism of how a variable is assigned to an object?
Consider a simple example. What happens when an object is passed as a parameter to a function? A copy of that object must be made so that the function can refer to that object locally. For an OO language that implicitly uses references, only the address of the object needs to be copied, whereas a true pass-by-value would require a copy of the complete memory contents of the object, which could potentially be very large (think a collection of objects or similar).
A detailed explanation of this involves getting into the guts of assembly. For example, why does a copy of an object to a function call even need to be made in the first place? Why does the indirection of an address not take longer than a direct value? Etc.
Related
What's the difference between passing by reference vs. passing by value?
It seems so obvious. How can I cast an object myObjet to the type of myObjet.getClass ?
I tried combinations of forName(), cast and others ... none seem to work :s
The problem is that I have a list of Objects and I would like to get them back to their original type (which is given by myObjet.getClass.getName()).
Regards,
Tim
Yes this is Java and it is certainly not wrong. Let me explain the problem. Picture a program that deals with simple forms like Squares and Circles that are derived classes from Form, the main class.
So there is a search function that returns a Form, but you have to provide the type and a reference of the form (a number, for example):
Form myForm= searchForm(String formType, String formRef)
I know what the Form it returns is going to be because I gave those arguments to the search function: a square, for instance. The returned object will still be a Form, but I want it to be of the Square class, so I need to cast it. It is compatible since Square inherits from Form.
The only problem is that "formType" is variable, it might indeed be Square, but it could also be "Circle". That is why I need a generic cast for the return object.
If I do a myForm.getClass().getName(), I get "Square". So I need to cast myForm to myForm.getClass().
Do you see the problem ?
Casting doesn't change the object itself. Casting only changes what the compiler allows you to do with the object.
Java provides two ways of describing what you can do with an object: classes and interfaces. The thing you cast to must be something the compiler knows about at compile time. Otherwise, the compiler can't prevent you from doing something silly, like trying to write myCircle.bark().
So you have two choices: if the classes have something in common (an implemented interface, or a class they all derive from) you could try casting to that common description. But it sounds like this is not what you want. Instead, Java forces you to do is to have a chain of if/else statements, which try to cast your object to each concrete class that you might want to do something with, like Square, Circle, etc.
But casting an object to its own class doesn't make sense, because it doesn't give the compiler any information at compile time about what methods the object does or does not have.