overloading

I have a method, in a class called "PlaceParser" that extends "ModelParser": protected Place parseModel(JSONObject element) ... A Place is a sub class of Model. Should the @Override annotation be added to the above code? As the method has a different return type, does this still count as overriding the base class method with the same name and arguments / does the return type alter the 'signature'? The "ModelParser" method looks like this "ModelT" also extends "Model": protected abstract ModelT parseModel(JSONObject element) throws JSONException; Update @Jon Skeet: The base class is declared

experimenting with Visitor pattern and generic method I found a kind of discrepancy in C#.NET. AFAIK C# compiler prefers an explicit overload to a generic method, therefore the following code: public abstract class A { public abstract void Accept(Visitor v); } public class B : A { public override void Accept(Visitor v) { v.Visit(this); } } public class C : A { public override void Accept(Visitor v) { v.Visit(this); } } public class D : A { public override void Accept(Visitor v) { v.Visit(this); } } public class Visitor { public void Visit(B b) { Console.WriteLine("visiting B"); } public void

I am trying to understand how Overloading in JAVA works and trying to get grasp of various overloading rules that are applied in case of widening, autoboxing and varargs in JAVA. I am not able to understand what is happening in the following scenario: package package1; public class JustAClass { public static void add(int a, long b) { System.out.println("all primitives"); } //public static void add(Integer a, long b) { // System.out.println("Wraper int, primitive long"); //} public static void add(int a, Long b) { System.out.println("Primitive int, Wrapper long"); } public static void add

Apparently (at least according to gcc -std=c99 ) C99 doesn't support function overloading. The reason for not supporting some new feature in C is usually backward compatibility, but in this case I can't think of a single case in which function overloading would break backward compatibility. What is the reasoning behind not including this basic feature? SingleNegationElimination To understand why you aren't likely to see overloading in C, it might help to better learn how overloading is handled by C++. After compiling code, but before it is ready to run, the intermediate object code must be

I am trying to implement overloading for division operator in python. class Fraction: def __init__(self,top,bottom): def gcd(m, n): while m % n != 0: old_m = m old_n = n m = old_n n = old_m % old_n return n common = gcd(top,bottom) self.num = top/common self.den = bottom/common def __str__ (self): return str(self.num) + "/" + str(self.den) def get_num(self): return self.num def get_den(self): return self.den def __add__(self, other_fraction): new_num = self.num * other_fraction.den + self.den * other_fraction.num new_den = self.den * other_fraction.den return Fraction(new_num, new_den) def _

How can I achieve something similar to this pattern in typescript? class A { Init(param1: number) { // some code } } class B extends A { Init(param1: number, param2: string) { // some more code } } The code snipped above appears like it should work, however on close inspection of How Typescript function overloading works it makes sense that an error is thrown: TS2415: 'Class 'B' incorrectly extends base class 'A'. Types of property 'Init' are incompatible. I know that constructor functions allow this behaviour, but I can't use constructors here as these objects are pooled for memory efficiency

Please consider the following code: class Abase{}; class A1:public Abase{}; class A2:public A1{}; //etc class Bbase{ public: virtual void f(Abase* a); virtual void f(A1* a); virtual void f(A2* a); }; class B1:public Bbase{ public: void f(A1* a); }; class B2:public Bbase{ public: void f(A2* a); }; int main(){ A1* a1=new A1(); A2* a2=new A2(); Bbase* b1=new B1(); Bbase* b2=new B2(); b1->f(a1); // calls B1::f(A1*), ok b2->f(a2); // calls B2::f(A2*), ok b2->f(a1); // calls Bbase::f(A1*), ok b1->f(a2); // calls Bbase::f(A2*), no- want B1::f(A1*)! } I'm interested to know why C++ chooses to resolve

I like to overload methods to support more and more default cases. What is the performance impact of method overloading? From your experience, is it advisable to overload methods? What is the limit? What are the workarounds? Overloading has no impact on performance; it's resolved by the compiler at compile-time. As for design guidance, see the design guidelines: http://msdn.microsoft.com/en-us/library/ms229029.aspx If you're using C# 4.0 you can save your fingers some work and use optional parameters . Performance impact, as far as I know, it's like defining a new method. The performance

struct A { A(int);}; struct B { explicit B(A); B(const B&);}; B b({0}); gcc 5.1.0 gives the error /dev/fd/63:3:8: error: call of overloaded 'B(<brace-enclosed initializer list>)' is ambiguous /dev/fd/63:3:8: note: candidates are: /dev/fd/63:2:27: note: B::B(const B&) /dev/fd/63:2:21: note: B::B(A) while clang 3.6.0 succeeds. Which one is right? Why? For gcc 5.1.0: http://melpon.org/wandbox/permlink/pVe9eyXgu26NEX6X For clang 3.6.0: http://melpon.org/wandbox/permlink/WOi1md2dc519SPW0 This may be similar to Direct list initialization compiles successfully, but normal direct initialization fails,

I am having a problem in my DSL with overloaded generic methods resulting in the compiler wanting me to add explicit parameter types: def alpha[T](fun: Int => T): String = fun(33).toString def beta [T](fun: Int => T): String = fun(66).toString def beta [T](thunk: => T): String = thunk.toString alpha { _ + 11 } // ok beta { _ + 22 } // "error: missing parameter type for expanded function" beta { _: Int => _ + 22 } // ok... ouch. Any chance I can get rid of the the clutter in the last line? EDIT: To demonstrate that the overloading is not an ambiguity problem to scalac per se, here is a version