This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
method vs function vs procedure vs class ?
Can some one give the differences between a method and a function?
Both are the same. Both are subroutines and both can return a value. Only difference may be the attachment to class. Method sounds more attached to a class but again, people use to call the non attached ones too methods. So, in that aspect too they can be seen as same
In java, and c++, by convention a function is called a method if it is member of a class.
also see here
In many languages methods don't return values while functions do.
Related
This question already has an answer here:
What are the practical advantages of currying?
(1 answer)
Closed 5 years ago.
I just know that it's it easy partial application and it's that it can (and does, for Haskell) simplify the syntax?
The main advantage is that it makes partial function application more convenient, and thereby encourages function composition.
One disadvantage is that it doesn't fit very well with a few other language features you might want, such as labeled, optional and variadic arguments. It's certainly not impossible to get it to work, OCaml for example has both labeled and optional arguments, but it gets quirky. How do you know when a function is partially applied, or fully applied and just not applying the optional argument? OCaml's solution is to assume partial application, and require functions to be "terminated" with a non-optional argument to be able to be fully applied without specifying all the optional arguments.
Another disadvantage pops up if the language is impure and has some form of type inference. It is then possible to partially apply a side-effectful function, discard the value without noticing that the type is incorrect, and thereby never have the side-effect occur. How prone a language is to mistakes like this depends on its type inference, but it's a fairly common beginner's mistake in a language such as OCaml. It can however be avoided by being a bit disciplined with type annotations.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
differences between 2 JUnit Assert classes
I have two junit-4.8.1.jars in my class path and my IDE's autocomplete is giving me the following two Assert classes:
junit.framework.Assert
org.junit.Assert
Which one should I use???
To quote a duplicate...
JUnit 3.X: junit.framework.Assert JUnit 4.X: org.junit.Assert
Prefer the newest one, especially when running JDK5 and higher with
annotation support.
I prefer org.junit package in all things JUnit. It's the source URL that the code comes from. The other is legacy that's left so it doesn't break old code.
Pick one and be consistent.
Niether, use MatcherAssert and Hamcrest with assertThat instead of assertTrue / assertFalse
MatcherAssert
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Where is the “proper” place to initialize class variables in AS3
I was wondering if anyone knows wether its better to instantiate class on it's variable declaration or within a constructor? For example, this:
protected var _errorHandler:ErrorHandler = new ErrorHandler();
or this:
protected var _errorHandler:ErrorHandler;
public function someClass() {
_errorHandler = new ErrorHandler();
}
A small point I think, but I want my code to robust and efficient as possible!
Thanks
Chris
Initialization in the constructor is preferred, for readability--for being able to easily see what gets initialized when. The least readable option would be to mix these, which I can't recommend.
There is a third option that you will see AS3 programmers use:
No initialization in the variable declarations
Empty (or nearly empty) constructor
All initialization done in one or more dedicated init() functions
This approach has two things to offer:
You can easily reset the object for re-use by calling init again
You can get around the limitation that AS3 does not let you overload the constructor like other similar languages (Java/C++/C#). You might want to, for example, be able to initialize a data structure with one or more different types of objects.
As far as performance goes, I believe your two examples would compile down to the same byte code. The AS3 compiler makes a special class initializer for static declarations that are outside the constructor, but for regular member variables initialized at declaration time, I expect it just moves the initializations to inside the constructor for you. But does it move them ahead or after what is explicitly in the contructor? I don't remember, which is why I cite readability as a main reason to put everything in the constructor yourself :-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Is Method Overloading considered part of polymorphism?
There are different types of polymorphism:
overloading polymorphism (also called Ad-hoc polymorphism)
overriding polymorphism
So yes it is part of polymorphism.
"Polymorphism" is just a word and doesn't have a globally agreed-upon, precise definition. You will not be enlightened by either a "yes" or a "no" answer to your question because the difference will be in the chosen definition of "polymorphism" and not in the essence of method overloading as a feature of any particular language. You can see the evidence of that in most of the other answers here, each introducing its own definition and then evaluating the language feature against it.
Strictly speaking polymorphism, from wikipedia:
is the ability of one type, A, to appear as and be used like another type, B.
So, method overloading as such is not considered part of this definition polymorphism, as the overloads are defined as part of one type.
If you are talking about inclusion polymorphism (normally thought of as overriding), that is a different matter and then, yes it is considered to be part of polymorphism.
inclusion polymorphism is a concept in type theory wherein a name may denote instances of many different classes as long as they are related by some common super class.
There are 2 types of polymorphism.
static
dynamic.
Overloading is of type static polymorphism.. overriding comes under dynamic (or run-time) polymorphism..
ref. http://en.wikipedia.org/wiki/Polymorphism_(computer_science) which describes it more.
No, overloading is not. Maybe you refer to method overriding which is indeed part of polymorphism.
To further clarify, From the wikipedia:
Polymorphism is not the same as method
overloading or method overriding.1
Polymorphism is only concerned with
the application of specific
implementations to an interface or a
more generic base class.
So I'd say method overriding AND method overloading and convenient features of some language regarding polymorphism but notthe main concern of polymorphism (in object oriented programming) which only regards to the capability of an object to act as if it was another object in its hierarchy chain.
Method overriding or overloading is not polymorphism.
The right way to put it is that Polymorphism can be implemented using method overriding or overloading and using other ways as well.
In order to implement Polymorphism using method overriding, you can override the behaviour of a method in a sub-class.
In order to implement Polymorphism using method overloading, you need to write many methods with the same name and the same number of parameters but with different data types and implement different behavious in these methods. Now that is also polymorphism.
Other ways to implement polymorphism is operator overloading and implementing interfaces.
Wikipedia pedantics aside, one way to think about polymorphism is: the ability for a single line of code / single method call to do different things at runtime depending on the type of the object instance used to make the call.
Method overloading does not change behaviors at runtime. Overloading gives you more choices for argument lists on the same method name when you're writing and compiling the code, but when it's compiled the choice is fixed in code forever.
Not to be confused with method overriding, which is part of polymorphism.
It's a necessary evil that is and should only be used as a complement. In the end overloads should only convert and eventually forward to the main method. OverloDing is necessary because most vms for staticalky dispatched environments don't know how to convert one type to another so the parameter fits the target and this is where one uses overloads to help out.
StringBuilder
Append(String) // main
Append(Boolean) // converts and calls append(String)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'd like to know how people decide whether to define a method as static. I'm aware that a method can only be defined as static if it doesn't require access to instance fields. So let's say we have a method that does not access instance fields, do you always define such a method as static, or only if you need to call it statically (without a reference to an instance).
Perhaps another way of asking the same question is whether you use static or non-static as the default?
I use static methods whenever I can. Advantages:
When calling a static method from inside an instance method, you can be sure that there are no side-effects on the state of the current object.
From inside a static method, you can be sure you don't accidentally modify any state of the object instance.
You can use a static method from outside the class without constructing an instance. If it was possible to make the method static, it clearly doesn't need an instance, so there's no need to require one.
Static methods may be slightly more efficient because no "this" pointer needs to be passed, and no dynamic dispatch is necessary.
Kevin Bourrillion wrote an insightful answer on this topic some time ago (admittedly from a Java perspective, but I think it's applicable to other languages too).
He argues that you should basically only use static methods for pure functions.
A "pure function" is any method which does not modify any state and whose
result depends on nothing but the
parameters provided to it. So, for
example, any function that performs
I/O (directly or indirectly) is not a
pure function, but Math.sqrt(), of
course, is.
I tend to agree. (Although in my own code, traditionally, I've probably used way too many static helper methods all over the place... :-P And this surely has made code that uses those methods harder to test.)
If what the method does depend solely on its arguments, you can make it static. If the method does not instantiate any other of your user defined classes, you can make it static. The default, though, is to have it as non-static.
Use static methods when you are performing operations that do not operate on instances of the class.
A perfect example would be a sqrt method of a Math class.
It depends. In languages where non-member functions are possible I'd say that most of the time, if the method could be made static, it should be made a non-member function instead, non-friend if possible. You can tell I have a mostly C++ background.
In "pure" OO languages where non-member functions are not possible it would depend on whether the method is only "incidentally" static (i.e. it just happens not to need access to instance members), or is truly logically static - it is a method of the whole class instead of for a particular instance.
Non static by default, static when I need the functionality to be available from at least two different classes, and I don't want to waste a constructor.
ps. Archimedes rules!
(C#) By default, I use static methods in static classes and non-static methods in non-static classes.
As I elaborate a class, I find myself naturally converging on making it entirely static or entirely non-static. Practially speaking, if I start wanting to define static members within a non-static class, I often find that it will eventually make the most sense to break those out into a separate static class -- either a utility class like Math or a global application class (like .NET's ConfigurationManager).
From an object-oriented perspective, a method is doing something to/with an object. So if you're using an instantiated object, it makes the most sense to me to think of that object's methods as non-static. Technically, you technically can make a non-static class have static members if they don't require access to an instance. But ostensibly, at least, a class's methods would still be doing something to/with that class, so I would still make them non-static. All things being equal, that is.
in context of python -
staticmethod are basically a normal function, we keep in the class only because of some logical reasons. classmethod takes 'class' as a first argument, default method takes instance aka self as a first argument but staticmethod does not takes any any argument.