Replies: 3 comments
-
Would a class or struct that implements the interface be able to define/override the operator, or would it only be defined once for all implementations? |
Beta Was this translation helpful? Give feedback.
-
this could be solved with static interface members: public IVector
{
static operator IVector +(IVector left, IVector right);
static operator IVector -(IVector left, IVector right);
static operator IVector *(IVector left, IVector right);
static operator IVector *(IVector vector, double scalar);
static operator IVector *(double scalar, IVector vector);
static operator IVector /(IVector left, IVector right);
// ...
} Further, #175 could also solve this: public static class VectorExtensions
{
public static IVector operator (+)(this IVector left, IVector right)
{
lar values = left.Zip(right, (l, r) => l+r).ToArray();
return new Vector(values);
}
///<summary>Vector cross product</summary>
public static IVector operator (**)(this IVector left, IVector right)
{
// V = ε[i,j] vl[i] vr[j]
return Sum((i,j) => LeviCivita[i,j] * left[i] * right[j], Enumerable.Range(0, left.Dimension));
}
// ...
} var vectorSum = vector1 (+) vector2;
// V = ε[i,j,k] v1[i] v2[j] v3[k]
var volume = (vector1 (**) vector2) (*) vector3; |
Beta Was this translation helpful? Give feedback.
-
Except then you'd have to solve static interface members. Interfaces rely on virtual dispatch to invoke the implemented/specialized implementation of the member and static members cannot participate in virtual dispatch as there is no instance and no vtable of overriding members. I'd expect that the combination of "extension everything" (#192) and "type classes"/"shapes" (#164) would probably satisfy the majority of use cases. |
Beta Was this translation helpful? Give feedback.
-
@stefc commented on Thu Oct 01 2015
I really want to see that I can use operator overloading also on Interfaces.
For example I've an interface IVector that have for example the immutable Add method :
IVector Add(IVector operand);
instead of
IVector x = a.Add(b);
I want to write
IVector x = a + b;
I don't see any reason why operator overloading is restricted to work only on normal classes.
@AlgorithmsAreCool commented on Thu Oct 01 2015
How would we define this operator? Typically they are in static methods in a class. Would you propose to allow static methods on interface definitions?
@stefc commented on Thu Oct 01 2015
I think operator overloading can be defined the same as extension methods, somewhere in a static class besides the interface declaration.
@AlgorithmsAreCool commented on Thu Oct 01 2015
Would this change also allow operator definitions for all types from extension methods?
@AlgorithmsAreCool commented on Thu Oct 01 2015
See also related discussion
Static interface members
https://roslyn.codeplex.com/discussions/541436
Possibility to provide operators in interface
https://roslyn.codeplex.com/discussions/570704
Static Interfaces Proposal
#2204
@daveaglick commented on Thu Oct 01 2015
FYI, there's also related discussion (particularly of static extensions and static interfaces) at #996 and #2204. #112 also looks related, though it's about extension properties and not operators.
@stefc commented on Thu Oct 01 2015
I don't see the operator overloading in the context of a static method inside the interface but that the operator overloading can resides somewhere not neccessary in the class/interface itself.
For the sideeffect with an existing operator overloading exsist on the class the compiler should be inform with a warning on that and the developer should be aware of this amigous usage. In my case I use either the interface operators or the class operator, if would define both it would be bad design I think. I see the interface as abstraction of the internals of a class.
@orthoxerox commented on Thu Oct 01 2015
@stefc Interfaces as they exist are very, very OOP-ish in their design, defining only virtual methods. Operators, on the other hand, were designed to be non-virtual, probably because C# is a single dispatch language, and it would be confusing to dispatch only on the runtime type of one of the operands.
I'd rather see operators implemented in templates/traits/"enhanced named generic constraints" than try and shoehorn them into interfaces.
@ashmind commented on Thu Oct 01 2015
I think this should be done through extension operators -- so it should be covered by #5165 / #4945.
@aluanhaddad commented on Mon Oct 05 2015
@ashmind agreed. #5165 is definitely the better proposal.
Beta Was this translation helpful? Give feedback.
All reactions