Cast Action<T> to Action<object> [modified]
-
That's exactly what I'm saying. The thing is though, generics were brought in for things like type safety and to prevent aid the developer move away from boxing/unboxing. By having object as the generic type, you've just gone back to having a boxing/unboxing issue - and you're no better off than just passing Action across rather than the generic Action.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
I understand that I should avoid boxing & un-boxing (and I do want to, and I do it everywhere), in this case it's not an option. Bit of a complex scenario I'll have to explain (and the code is part of a 5 000 file solution), but I'm quite irritated that this is disallowed, I thought polymorphism / covariance / contravariance is exactly about this...
____________________________________________________________ Be brave little warrior, be VERY brave
-
I understand that I should avoid boxing & un-boxing (and I do want to, and I do it everywhere), in this case it's not an option. Bit of a complex scenario I'll have to explain (and the code is part of a 5 000 file solution), but I'm quite irritated that this is disallowed, I thought polymorphism / covariance / contravariance is exactly about this...
____________________________________________________________ Be brave little warrior, be VERY brave
It is, for objects - aka reference-types, not for value-types. C# is really strict on the difference. The posted alternative with the interface does look like it (could) solve your problem. Alternatively, you could decide only to pass objects, and to wrap your ints in a
MyIntclass.I are Troll :suss:
-
After much painfull and brain numbing reading I still don't understand why its not possible to cast between
Action<T>andAction<object>, can anyone please explain this in small words (I currently have the brain of a 5 year old). There was a poem written along time ago by a person dying with lots of pain, he called it 'Brother Pain', I'm about to write a poem called 'Brother Cannot implicitly convert type 'System.Action<T>' to 'System.Action<object>'' An example:public class Base
{
public Func<object> OnComplete {get;set;}
public Base(Func<object> onComplete)
{
OnComplete = onComplete;
}
}
public class GenericBase<T> : Base
{
public GenericBase(Func<T> onComplete) : base(onComplete) //Error
{
OnComplete = onComplete; //Error
}
}____________________________________________________________ Be brave little warrior, be VERY brave
modified on Thursday, March 31, 2011 3:22 AM
Because it just can't. If asked questions such as this I like to mutter something about Covariance and Contravariance and wonder off. Usually works in the office environment anyway.
Regards, Rob Philpott.
-
I understand that I should avoid boxing & un-boxing (and I do want to, and I do it everywhere), in this case it's not an option. Bit of a complex scenario I'll have to explain (and the code is part of a 5 000 file solution), but I'm quite irritated that this is disallowed, I thought polymorphism / covariance / contravariance is exactly about this...
____________________________________________________________ Be brave little warrior, be VERY brave
It's a design issue and it makes sense when you think about it. If you want to use a collection of type object, then use ArrayList. The generic List is a strongly typed version of ArrayList, so if strong typing is not required, use ArrayList.
"You get that on the big jobs."
-
Adriaan Davel wrote:
this
object x = 1;worksThat wraps your value-type with a reference-type; your number is actually stored in the object, but a number is not an object itself.
I are Troll :suss:
In .net, everything is an object. :-D
-
Because it just can't. If asked questions such as this I like to mutter something about Covariance and Contravariance and wonder off. Usually works in the office environment anyway.
Regards, Rob Philpott.
Rob Philpott wrote:
Covariance and Contravariance
I thought those were added in .net 4.
-
In .net, everything is an object. :-D
-
Rob Philpott wrote:
Covariance and Contravariance
I thought those were added in .net 4.
You see, I'd have wondered off by the point anyone questions it... This is what I'm thinking of: http://blogs.msdn.com/b/ericlippert/archive/2007/10/19/covariance-and-contravariance-in-c-part-three-member-group-conversion-variance.aspx[^]
Regards, Rob Philpott.
-
That's one of those generalizations that I loathe. Yes, structs are objects too. ..but that doesn't make 'em interchangeable :)
I are Troll :suss:
-
Eddy Vluggen wrote:
but that doesn't make 'em interchangeable
Yes it does, assuming the container being used to intercahnge them types the variable as object.
J4amieC wrote:
Yes it does, assuming the container being used to intercahnge them types the variable as object.
The keyword here is "assuming", and your assumption is a leaky abstraction :) Reference-types are objects, value-types can be boxed in an reference-type. And no, a namespace isn't an object, it's not even a type. Once you state that everything is an object, people will assume that anything can be used as a base to derive from (since OO is partly about inheriting from existing objects).
I are Troll :suss:
-
J4amieC wrote:
Yes it does, assuming the container being used to intercahnge them types the variable as object.
The keyword here is "assuming", and your assumption is a leaky abstraction :) Reference-types are objects, value-types can be boxed in an reference-type. And no, a namespace isn't an object, it's not even a type. Once you state that everything is an object, people will assume that anything can be used as a base to derive from (since OO is partly about inheriting from existing objects).
I are Troll :suss:
-
Eddy Vluggen wrote:
Once you state that everything is an object, people will assume that anything can be used as a base to derive from
Any non-sealed Type can be used as a base to derive from. What's your point?
J4amieC wrote:
Any non-sealed Type can be used as a base to derive from.
You can circumvent the impossibility of inheriting a structure by pointing out that it's a sealed class - but that doesn't change the validity of my statement. I took the example of a namespace to prevent the hairsplitting discussion that structs are merely mutilated classes under the hood :)
J4amieC wrote:
What's your point?
That the text "everything is an object" is incorrect. I stated that literally, didn't I? :laugh:
I are Troll :suss:
-
J4amieC wrote:
Any non-sealed Type can be used as a base to derive from.
You can circumvent the impossibility of inheriting a structure by pointing out that it's a sealed class - but that doesn't change the validity of my statement. I took the example of a namespace to prevent the hairsplitting discussion that structs are merely mutilated classes under the hood :)
J4amieC wrote:
What's your point?
That the text "everything is an object" is incorrect. I stated that literally, didn't I? :laugh:
I are Troll :suss:
(Whoops, sorry to have started that. :-O )