Tag Info

Hot answers tagged

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 ...


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 ...


18

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 ...


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 ...


8

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.


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

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. ...


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

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 { ...


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 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 ...


3

Essentially to have the parameters of the method dictate how the method will behave. A quick example would be: class Calc{ //... public int sum(int a, int b){ return a+b; } public double sum(double a, double b){ return a+b; } //... } If you pass the method sum(a,b) a couple of integers it knows that it should call ...


3

You need to be careful designing APIs that have methods overloaded on parameter type: the methods need to do exactly the same things, otherwise the users will be confused. Two methods that take a matrix, one taking a "straight" one and the other taking a transposed one, are definitely not doing the same thing, so overloads on different types is an unlikely ...


2

I think that a good way to express this is to focus on the final result, not on changes made to the class over time. Thus, instead of saying "I overloaded 'foo' with 'foo(other parameters)'," you say "foo is an overloaded function, with 'foo()' and 'foo(other parameters).'"


2

You overload when you wish to support different types: public overload void MyMethod(int value) { } public overload void MyMethod(bool value) { } public overload void MyMethod(string value) { } or to support a progressive interface using different parameter lists: public overload void MyOtherMethod() { this.MyOtherMethod(DefaultValue); } public ...


2

When dealing with large object, this is really common. While adding new methods increases performance, it significantly decreases the maintainability. And again you need to choose between those two. I suggest you have a method that returns (not necessarily the smallest) commonly used data, another that returns the whole object, and probably a few more for ...


2

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