Hot answers tagged

56

The main reason is for performance. The "unlimited arguments" syntactical sugar is actually an array of Strings. If you are only passing one string, why create an array with only one string? Especially if ~90% of the invocations of this method will be with 3 or fewer arguments, there is no need for the heavier weight array object. It's a little lighter in ...


27

To answer this, you first need a definition for "syntactic sugar." I'll go with Wikipedia's: In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an ...


24

Who told you PHP doesn't support function overloading?!!! Actually PHP does support function overloading, but in a different way. PHP's overloading features are different from Java's: PHP's interpretation of "overloading" is different than most object oriented languages. Overloading traditionally provides the ability to have multiple methods with the ...


21

When talking about overloads, the name of the function is overloaded, not the function itself. The functions overloading the name are "overloads" and overload the name, but not each other. In your example, "public void foo()" and "public void foo( string bar )" both overload the name "foo". Therefore, you cannot speak in terms of overloader and overloadee of ...


18

This is a relatively minor issue compared to many other bad readability practices you could be susceptible to, so I'd say it's mostly a matter of taste how you name your methods. With that said, if you are going to do something about it, I would follow this practice: Overload if... The methods obey nearly the same contract but simply operate on different ...


14

I can see where they're coming from, but as rules I would say these are way too specific for 100% restriction in a language design. Gigantic 18+ layer convoluted inheritance schemes are pretty well-established as an anti-pattern for instance but inheriting 1-3 levels deep can be perfectly reasonable for solving certain problems depending on what other ...


13

Classes, method overloading, operator overloading... they are all tools. They are suitable in some circumstances, not in others. Don't try to apply labels like "evil" to such things; instead, strive to understand them so you can decide for yourself whether they are useful or not.


13

The term syntactic sugar typically refers to cases where the feature is defined by a substitution. The language doesn't define what a feature does, instead it defines that it is exactly equivalent to something else. So for example, for-each loops for(Object alpha: alphas) { } Becomes: for(Iterator<Object> iter = alpha.iterator(); iter.hasNext()) { ...


11

I would simply say foo is overloaded. There is certainly no master/slave or parent/child relationship going on here.


11

Quoting http://marc.info/?l=php-internals&m=121578194822276&w=2 Was static member overloading added in PHP 5.3? I noticed that static method overloading was (__callStatic). The two would complement each other and it just seems natural to add these as well. I did notice that they are apart of the "static-class" RFC and a bug report, but ...


10

If the language supports them properly (e.g. type-safety, if applicable), I would prefer optional arguments for the following reasons: They convey your intent better so noone suspects that your function overload will do something different (which it probably shouldn't anyway). Less code to maintain, even if the function overload only delegates to the more ...


10

I really wonder why the version with actual IO has been added to the class in the first place. What's the point here? How is that the responsibility of the class? Why not add a method to load the words from a zipped file, or from an .xml or a .json or a .doc or an SQL database or over http or ftp or whatever? Because it's not the responsibility of the ...


9

I vote for "Giving the methods different names" option especially if performance matters. Don't use method1(int[][]) and method2(int[][]). Use method(int[][]) and method_transposed(int[][]) for example. Method name should always help the reader to understand what it does.


9

It complicates type checking. When you only permit overloading based on argument types, and only permit deducing variable types from their initialisers, all of your type information flows in one direction: up the syntax tree. var x = f(); given f : () -> int [upward] given () : () [upward] therefore f() : int [upward] ...


8

Not a "Traditional Overloading" full support, only partial. A DEFINITION: "Traditional Overloading" provides, when calling method, the ability to have multiple methods with the same name but different quantities and types of arguments. For method declaration, it provides the option to express a separate/isolated declaration for each overloaded function. ...


8

Given that name-mangling works, doesn't it have to be nothing more than syntactic sugar? It allows the caller to imagine he is calling the same function, when he isn't. But he could know the real names of all his functions. Only if it were possible to achieve delayed polymorphism by passing an untyped variable into a typed function and have its type ...


7

Depending on the language, it is syntactic sugar or not. In C++ for instance, you can do things using overloading and templates which would not be possible without complications (write manually all instantiations of the template or add a lot of template parameters). Note that dynamic dispatch is a form of overloading, dynamically resolved on some ...


5

This violates at least three principles of object-oriented programming, and potentially a fourth. First, this violates the Principle of Least Astonishment. Let's assume we are given documentation for only one of the methods, and we have to infer what the other does. First: // Reads words from a file public void LoadWords(string) // ??? public void ...


5

For contemporary languages, it's just syntactic sugar; in a completely language-agnostic sort of way, it's more than that. Previously this answer stated simply that it's more than syntactic sugar, but if you'll see in the comments, Falco raised the point that there was one piece of the puzzle that contemporary languages appear to all be missing; they don't ...


4

If you rename a method, it is no longer going to be overloaded. In and of itself, overloading doesn't necessarily make code less readable, however it can make the implementation more difficult to follow if the syntax isn't clear. Many languages use method overloading as a means to present an interface to functionality where the parameters may be optional ...


4

I would recommend using a different name, in every case. It's possible that at some time in the future, you'll want to add another method, say List<Car> findByMake(String make), in contrast to List<Car> findByModel(String model). So suddenly, calling everything find stops making sense. Your methods also less likely to inadvertently be used ...


4

I would say that overloading is appropriate when both of the methods are semantically equivalent. To steal from dukeofgaming's examples: These are overloaded appropriately: public int sum(int a, int b){ return a+b; } public double sum(double a, double b){ return a+b; } These are not: public int sum(int a, int b){ return a+b; } public ...


4

Syntax-wise, I'd create an intermediate query-building object with a fluid interface: // all the basic, cheap to query fields AssetDto a = AssetRetriever(asset_id).fetch() // some common expensive fields AssetDto a = AssetRetriever(asset_id).withOwner().withQuestion().fetch() // numerous less common fields may not command dedicated methods AssetDto a = ...


4

Method overloading is typically used for variants of the same behavior: Do the same thing for different types A default version with fewer parameters and a complex version that allows more control via additional parameters. A good example are the various massively overloaded methods in java.util.Arrays: they do the same thing on arrays of the various ...


4

However, that only makes sense if I create a different class for each different element, which doesn't seem right To me, this feels perfectly right, since, it is just an application of the classic "strategy" pattern (in this case a RoundScoreCalculationStrategy). I would design this in a way like this: interface RoundScoreCalculationStrategy { ...


4

It's one use of overloading In some programming languages, function overloading or method overloading is the ability to create multiple methods of the same name with different implementations. Calls to an overloaded function will run a specific implementation of that function appropriate to the context of the call, allowing one function call to perform ...


4

As said the methods with different parameter lists is simple overloading. The fact they call each other is simply a refactor to reduce duplication in the code. You could copy and paste the real implementation into each method body, but that would create problems when the common code changed (you would need to update the code in each method) so having the ...


3

As you stated, there isn't a way (until Java 8) for an interface to require a static method. There also isn't a way to override a static method, so which documentation could actually be inherited? I see a few options: If the documentation on the interface describes the method (which I would expect - how are implementers supposed to know about the load() ...


3

Version #2 is FAR preferable, although the overall design is often considered a code smell. Note that more recent C# dialects allow for optional parameters, so you could combine your base and overload. class foo { public foo(string a, bool no_tricks = false) { variable = a; if(no_tricks == false) { TrickyFunction(a); } } } (And, of ...


3

I believe the common approach is to encapsulate some (or all) of the parameters into a class and have that as a parameter: DoThing(string foo, string bar, DoThingParameters parameters = null); If you use C#, you can then write those parameters directly inline when calling the method: DoThing(foo, bar, new DoThingParameters { More = value, AndMore = ...



Only top voted, non community-wiki answers of a minimum length are eligible