How can I accomplish operator overloading in a way that is convenient to use?
As you can see, putting an operator overload in a class does nothing. Also, if I use "abstract", I can't even call the Bark() method on Dog.
Operator overloading shouldn't be so convoluted and unviable.
Operator overloading is only for abstracts at the moment. What you can do is to create and to apply a macro to your context (where your operations are executed) and transform the expression tree so that the operations are mapped to the right methods.
In haxe 3.1.3, you can add #:forward before the abstract to forward underlying attributes and methods to the abstract.
#:forward // add this!
abstract Dog2(Dog) to Dog from Dog
{
...
}
new Dog2().Bark(); // no more error!
You can also forward specific methods/attributes to the abstract. See Forwarding abstract fields
Related
I have an enum with many values; error codes for example, or some official list of coded values. In my application, I have several functions where only a subset of those values is admissible. How can I derive restricted enums that contain only a subset of the original enum?
For example, I have an externally provided dictionary of error codes that model as enum:
enum class ApiError(val: errorCode: Int) {
INCORRECT_CHARACTER(1),
MISSING_VALUE(2),
TOO_SMALL(3),
TOO_LARGE(4)
}
In one function call, only the TOO_SMALL and TOO_LARGE errors may result, in another only INCORRECT_CHARACTER or MISSING_VALUE. Instead of defining two new enums for these particular error return values, I would like both to somehow reference the complete enum with all error codes.
To be more precise: Assume I have a function fun handleError(error: ApiError); inside this function, I want to be able to write an exhaustive when pattern match that covers all enum cases. However, I also want to be able to pass an argument of a restricted enum type to that same function, where that restricted type can take on only a subset of the enum values, as in the example above.
What comes to mind (but does not work in Kotlin) would be to subclass the ApiError enum while restricting the admissible values in each subclass. Is there a Kotlin solution that does something similar?
The opposite question – to subclass an enum for extension – has been discussed here at length. As far as I understand, the objections there do not apply when restricting the potential enum values.
And just for curiosity: I suppose the above question is some concrete and utterly misspecified version of a some type theoretical problem. Can someone provide pointers to the proper theory and terminology?
What comes to mind (but does not work in Kotlin) would be to subclass the APIError enum while restricting the admissible values in each subclass. Is there a Kotlin solution that does something similar?
Yes, if you need to express a hierarchy, you could use sealed class/interface hierarchies with objects as leaves.
sealed class ApiError(val code: Int) {
object IncorrectCharacter : ApiError(1)
object MissingValue : ApiError(2)
}
sealed class SizeError(code: Int): ApiError(code) {
object TooSmall : SizeError(3)
object TooLarge : SizeError(4)
}
What you lose here compared to enums is the ability to list all possible values using ApiError.values(). But in this case it might not be an issue.
Also it might not be ideal to serialize (and even more so, deserialize), depending on which serialization library you're using.
is there a way in typescript to extend a class in this way:
class ChildClass<Wrapper<A>> extends SuperClass<A>
This doesn't work but the idea would be to wrap the generics type into a known construct. Here are the docs:
https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md
This sounds a bit similar to this issue:
Can you subclass a generics class with a specific typed class?
I don't do much oop so I'm not very familiar with stuff like covariance and contravariance, any help would be appreciated.
It maeks no sense to write ChildClass<Wrapper<A>> before the extends, because there you declare the generic type parameters. That means you can give them a name and, if you need to, a constraint (for example ChildClass<A extends Wrapper>). What does Wrapper<A> mean in this context? The compiler can make no sense of it.
What is absolutely possible is to use Wrapper<A> on the other side of the extends, because there A is not a (formal) type parameter, but a type argument. That means you are using the type parameter previously defined and there you can generate new types with it.
So depending on what you actually want to do, there are two options for you:
A is assignable to Wrapper
When you want to make sure the A is a Wrapper or a derived class, use a generic constraint:
class ChildClass<A extends Wrapper> extends SuperClass<A>
A is a type argument of Wrapper<>
If Wrapper<> is itself a generic class or interface and you want to use A as its type argument, do this:
class ChildClass<A> extends SuperClass<Wrapper<A>>
I know there are various capabilities in Java with reflection.
For example:
Class<?> clazz = Class.forName("java.util.Date");
Object ins = clazz.newInstance();
I wonder if I could pass class dynamicaly in some method declaration in <> tags (or there is other way to do it if it must be fixed). I would like to change that class declaration dynamicaly; because I would like to write generic method for all types of classes.
In there, I have this:
List<Country>
Can I write it something diffrent with reflection? For example can it be somehow be achieved to pass class as parameter (or how else should be this done):
List<ins>
? I would appreciate examples.
This cannot be done because generics are a compile time feature. Once code is compiled, the only place where generics are exists are at method signatures, and they are only used for compiling new code.
When working with reflection, you are basicly working with raw types, and need to code according to that, that means, you can cast the returned result of newInstance() to the list type your need, for example:
List<Country> ins = (List<Country>)clazz.newInstance();
This is a safe operation to do, because you know at that point its empty, and isn't passed to any outside code.
I don't think this is possible. Generics in Java are implemented in a way that prohibits runtime access.
Generics are there so that the compiler can verify correct typing, but are no longer present at runtime (this is called "type erasure"). Reflection deals with the runtime representation of types only. As far as I know the only case where reflection has to deal with generics is to find out "fixed" type parameters of sub-classes, e.g. when you have class Bar<T> and class Foo extends Bar<String>, you can find out that the T of Bar is fixed to String in Foo using reflection. However, this is information found in the class file, too. Except that, reflection can only see or create raw-types.
It is certainly not for good OOP design - as the need for common behavior of all instances of a derived class is quite valid conceptually. Moreover, it would make for so much cleaner code if one could just say Data.parse(file), have the common parse() code in the base class and let overriding do its magic than having to implement mostly similar code in all data subtypes and be careful to call DataSybtype.parse(file) - ugly ugly ugly
So there must be a reason - like Performance ?
As a bonus - are there OOP languages that do allow this ?
Java-specific arguments are welcome as that's what I am used to - but I believe the answer is language agnostic.
EDIT : one could ideally :
<T> void method(Iface<? extends T> ifaceImpl){
T.staticMeth(); // here the right override would be called
}
This will also fail due to erasure (in java at least) - if erasure is at work one needs (would need) to actually pass the class :
<T, K extends T> void method(Iface<K> ifaceImpl, Class<K> cls){
cls.staticMeth(); // compile error
}
Does it make sense ? Are there languages doing this already ? Is there a workaround apart from reflection ?
Speaking to C++
class Foo {
public:
static void staticFn(int i);
virtual void virtFn(int i);
};
The virtual function is a member function - that is, it is called with a this pointer from which to look up the vtable and find the correct function to call.
The static function, explicitly, does not operate on a member, so there is no this object from which to look up the vtable.
When you invoke a static member function as above, you are explicitly providing a fixed, static, function pointer.
foo->virtFn(1);
expands out to something vaguely like
foo->_vtable[0](foo, 1);
while
foo->staticFn(1);
expands to a simple function call
Foo##staticFn(1);
The whole point of "static" is that it is object-independent. Thus it would be impossible to virtualize.
consider a standard c# 'function'
public void foo()
{
//some code
}
In c or c++ this is called a 'function' - even if taking no parameters and returning no value. In another language maybe it would be a 'procedure'.
In object orientation speak it would be called a 'method' if a class member.
What would be the correct term to use in c#?
Method : function of a class.
Function : function out of a class, possible only in full-object languages (like C++, C, etc.)
Procedure : function that return nothing/void. I personnaly don't like this word, I'd rather use 'function'
Make your choice =)
Edit : Just to be more precise, Method, function and procedure are OOP words to describe a subroutine. Some languages have their own vocabulary such as "predicate" in Prolog, or "constructor" in C++/C#/Java, or even "property" in C#.
Just to confuse the issue futher: (from C# Language Specification)
7.4 Function members
Function members are members that contain executable statements. Function members are always members of types and cannot be members of namespaces. C# defines the following categories of function members:
* Methods
* Properties
* Events
* Indexers
* User-defined operators
* Instance constructors
* Static constructors
* Destructors
And
10. Classes
A class is a data structure that may contain data members (constants and fields), function members (methods, properties, events, indexers, operators, instance constructors, destructors and static constructors), and nested types. Class types support inheritance, a mechanism whereby a derived class can extend and specialize a base class.
So "function member" or "method" would be correct for C#.
Method is OOP abstraction term. They describe behaviour(a verb) of an object.
They are equivalent to some of the procedural programming's functions and procedures.
(the properties etc are also function and procedures).
So, function is a program within program that returns some values.
Procedure is a program within program that does something.
Methods, Properties etc, etc are a next level of abstraction(used in OOP). They are wrapped around functions and procedures.
I think in C# call it a method because C# is object oriented language.
If a "Function" is part of a class I call it a method.
If I was coding in C (i.e. in proceedural or non OO idiom) I call it a function.
I personally don't use the word proceedure to refer to a "Function"
I thought (in Ada) that a 'procedure' is the correct term generally, and a 'function' is a procedure which is guaranteed to be side-effect free, that is, it only reads from and does manipulation on data, and returns it, but does not write anything or have any 'side-effects'.
I'm a Java guy anyway, I call everything a function even though it should be called a method.
I think method is the correct term, but I doubt you'll get any funny glares for using any of the other suggested names.
Since I spent a lot of time with ADA I would call that a "procedure" since it has no return value. If it had a return value, I would have called it a "function".
I've never seen the point of saying "Method", though that is most likely the correct term to use when talking about functions/procedures that are members of a class. Never really saw the use of yet another term for the same thing.