public class JavaForumParticipant {
public String respondToPost(Post toRead) {
String content = toRead.getBody();
// code for providing a meaningful response to the post...
}
}
public class EmbitteredLongTermJavaForumParticipant extends JavaForumParticipant {
public String respondToPost(Post toRead) {
BSSniffer sniffer = new BSSniffer();
if (sniffer.isHomework(toRead) || sniffer.isMeaninglessOverbroadQuestion(toRead) || sniffer.isCompleteGibberish(toRead)) {
return "Piss off.";
}
else {
// code for providing a meaningful response to the post...
}
}
}
public class Test {
public static void main(String[] arguments) {
JavaForumParticipant drake = new EmbitteredLongTermJavaForumParticipant();
Post thePost = new Post("HowardDan", " What are different types of polymorphism in Java OOP? \nI read overriding is runtime. Please provide code sample as how overriding can happen at runtime.");
String response = drake.respondToPost(thePost);
System.out.println(response); // output is "Piss off."
}
}
Sorry, forgot the code tags.
public class JavaForumParticipant {
public String respondToPost(Post toRead) {
String content = toRead.getBody();
// code for providing a meaningful response to the post...
}
}
public class EmbitteredLongTermJavaForumParticipant extends JavaForumParticipant {
public String respondToPost(Post toRead) {
BSSniffer sniffer = new BSSniffer();
if (sniffer.isHomework(toRead) || sniffer.isMeaninglessOverbroadQuestion(toRead) || sniffer.isCompleteGibberish(toRead)) {
return "Piss off.";
}
else {
// code for providing a meaningful response to the post...
}
}
}
public class Test {
public static void main(String[] arguments) {
JavaForumParticipant drake = new EmbitteredLongTermJavaForumParticipant();
Post thePost = new Post("HowardDan", " What are different types of polymorphism in Java OOP? \nI read overriding is runtime. Please provide code sample as how overriding can happen at runtime.");
String response = drake.respondToPost(thePost);
System.out.println(response); // output is "Piss off."
}
}
> What are different types of polymorphism in Java OOP?
Only one "kind" that I know of.
You can override methods, where a subclass changes its implementation of a particular method to differ from its parent class, or overloading, where one class will have more than one method with the same name and return type, just different parameter and exception signatures.
The compiler checks for syntactic correctness at compile time, but when the program runs it uses the runtime types of parameters and classes.
> I read overriding is runtime.
That's right.
> Please provide code
> sample as how overriding can happen at runtime.
public interface Foo
{
public void print();
}
class Bar implements Foo
{
public void print() { System.out.println("I"m a Foo and a Bar"); }
}
class Baz implements Foo
{
public void print() { System.out.println("I"m a Foo and a Baz"); }
}
That's polymorphic. A reference to a Foo can be made to act like a Bar or a Baz at runtime.
%
There are various forms of usable/pragmatic polymorphism in Java like
1) Overloading - (Compile time)
2) Overriding using inheritance - (Runtime)
3) Overriding using interface ?(Runtime)
Polymorphism ?one name many forms thus provides abstraction
Overloading - same method name, different parameter list
Overriding - same method name, same parameter list, same return type, same or higher visibility, same or less or child exceptions (may add runtime exceptions)
Example of overriding using interface
List listEmp = new ArrayList();
listEmp is referenced variable for instantiated ArrayList object.
Following code sample shows compile time polymorphism using 揙verloading?
class AClass{
void aMethod() { System.out.println("aMethod()");}
void bMethod(int x){ System.out.println("bMethod(int x)"); }
}
public class MainClass{
public static void main(String[] args){
AClass aClass = new AClass();
aClass.aMethod();
aClass.bMethod(3);
}
}
Output
aMethod()
bMethod(int x)
The compiler needs matching method to COMPILE but determination of which method is called happens at RUNTIME.
Following code sample shows runtime polymorphism using 揙verrriding using inheritance?
class ParentClass {
void aMethod () { System.out.println("parentClass"); }
}
class ChildClass {
void aMethod () { System.out.println("childClass");}
}
class MainClass {
public static void main(String[] args){
ParentClass parentClass = new ChildClass();
parentClass. aMethod ();
}}
Output
childClass
In MainClass "parentClass.foo()" COMPILED because of syntax matching foo() method in referenced variable ParentClass. But at RUNTIME foo method of actual instantiated ChildClass creates output "childClass?br>
Following code sample shows runtime polymorphism using 揙verrriding using interface?
interface AInterface {
public void aMethod();
}
class AClass implements AInterface {
public void aMethod() { System.out.println("AClass"); }
}
public class MainClass {
public static void main(String[] args) {
AInterface aInterface = new AClass();
aInterface.aMethod();
}
}
PS: There are many varied theoretical and technical definitions of polymorphism.
> There are various forms of usable/pragmatic
> polymorphism in Java like
>
> 1) Overloading - (Compile time)
> 2) Overriding using inheritance - (Runtime)
> 3) Overriding using interface ?(Runtime)
I would not distinguish between (2) and (3).
> PS: There are many varied theoretical and technical
> definitions of polymorphism.
I disagree with this, too. Just one definition that I know of, and it's runtime typing. Please post examples of "many".
%
There was a thread a while back in which the OP asked about the distinction between "pure polymorphism" and "ad hoc polymorphism" (although actually, his question was much less clear than how I just stated it). I did some reading at that time and apparently the concept of polymorphism can be interpreted pretty broadly.
The example of "ad hoc" polymorphism presented by one web site was the use of the + operator in java to concatenate Strings. Since the + operator can operate on unrelated types it is considered to have polymorphic functionality. The same would go for this:
public void doSomething(String[] strings) {/* do something with the Strings*/}
public void doSomething(Collection<String> strings){/* do something with the Strings*/}
Drake
I've once seen someone argue that a well designed equals method exhibits polymorphic behaviour since it behaves differently depending on an objects runtime class. I suppose this would be ad-hoc polymorphism too, if it was any kind.
Note that I don't necessarily agree with the above view. Just trying to illustrate how different some views can be.
> I've once seen someone argue that a well designed
> equals method exhibits polymorphic behaviour since it
> behaves differently depending on an objects runtime
> class. I suppose this would be ad-hoc polymorphism
> too, if it was any kind.
Of course that's how equals behaves. The JVM will figure out that it should call your equals instead of the java.lang.Object if you have one.
But that's just polymorphism. I don't agree that there are different "kinds". I don't recall reading that "ad hoc" is a common term.
> Note that I don't necessarily agree with the above
> view. Just trying to illustrate how different some
> views can be.
This one sounds like it's not widely held. There are people who hold the view that thunder is the sound made when angels bowl in heaven, but that doesn't make it right or acceptable.
%
> Of course that's how equals behaves. The JVM will
> figure out that it should call your equals instead of
> the java.lang.Object if you have one.
That's not what he meant. His point was that the method behaves differently depending on the runtime type of the object passed to equals
Point p = new Point(0, 0);
Object o = new Object();
System.out.println(p.equals(o)); //false
o = new Point(0, 0);
System.out.println(p.equals(o)); //true
right, that's polymorphism and run time typing.I think i understood what he meant.
Your example does indeed work (you knew that):
import java.awt.Point;
public class AdHocPolymorphism
{
public static void main(String [] args)
{
Point p = new Point(0, 0);
Object o = new Object();
System.out.println(p.equals(o)); //false
o = new Point(0, 0);
System.out.println(p.equals(o)); //true
}
}
It's because of the way the equals method was written for java.awt.Point:
public boolean equals(Object obj) {
if (obj instanceof Point) {
Point pt = (Point)obj;
return (x == pt.x) && (y == pt.y);
}
return super.equals(obj);
}
The compile time type of the parameter is java.lang.Object. The method checks to see if its runtime type is java.awt.Point. If it is, the values of x and y are compared. If it's not, the equals method for the superclass java.awt.geom.Point2D is called.
Let's look at the Point2D equals method:
public boolean equals(Object obj) {
if (obj instanceof Point2D) {
Point2D p2d = (Point2D) obj;
return (getX() == p2d.getX()) && (getY() == p2d.getY());
}
return super.equals(obj);
}
It's doing the same thing: if the parameter isn't an instance of Point2D, the Object equals is called.
i'm saying there's only one mechanism. all this stuff about "ad hoc" and different flavors is incorrect.
i'd recommend going to the java language specification, which is the definitive description of how the jvm works, and see if there are more than one way of doing runtime typing this way. because that's all polymorphism is - runtime, dynamic typing as opposed to compile time, static typing.
There's no magic here.
%
No matter that polymorphism is, in the end, always about runtime type versus compile time type. There's a lot of different places where it happens. So far we've seen polymorphism "caused by" overloading, overriding, and instanceof checks. Those, IMHO, are different flavors of polymorphism, even if in the end it always boils down to the same.
If I may, without offense, saying there can only be one type of polymorphism sounds like saying there can be only one type of vehicle: a vehicle.
> No matter that polymorphism is, in the end, always
> about runtime type versus compile time type. There's
> a lot of different places where it happens. So far
> we've seen polymorphism "caused by" overloading,
> overriding, and instanceof checks. Those, IMHO,
> are different flavors of polymorphism, even if
> in the end it always boils down to the same.
An instanceof check isn't an example of polymorphism. instanceof is just an operator. It's a way that you can change what happens in code based on runtime types, but it's actually anti-polymorphic. Once you encode this in "if (x instanceof Foo)" code, you've lost the benefit that polymorphism gives. You can only extend code like that by adding more if clauses. Polymorphism lets you do it by adding classes, without having to change existing code. Runtime typing by the JVM, not your code, is where the magic is.
> If I may, without offense, saying there can only be
> one type of polymorphism sounds like saying there can
> be only one type of vehicle: a vehicle.
You may without giving offense, but I don't believe you're correct.
No, the analogy doesn't hold. There can obviously be more than one type of vehicle. There's only one runtime binding mechanism.
I'll put the onus on you: Please cite the sections of the JLS that describe the different flavors that you're alluding to. I don't mean overriding and overloading, because both are just different ways that runtime binding manifests itself.
And if there are indeed many kinds of polymorphism beyond what we're citing, what difference does it make? Do you write Java differently?
You seem to be insisting on a point simply so you don't have to say your view was incorrect.
%
I haven't checked, but I'm perfectly agreeable to the idea that java has only one way of runtime binding. And if you equate polymorphism exclusively with that then, yes, java has only one kind of polymorphism. There are however, a lot of varying definitions of polymorphism, on varying levels of abstraction. For example, this quote can be found on [url http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29]a wikipedia page[/url]:
There are two fundamentally different kinds of polymorphism, as first informally described by Christopher Strachey in 1967. If the range of actual types that can be used is finite and the combinations must be specified individually prior to use, it is called ad-hoc polymorphism. If all code is written without mention of any specific type and thus can be used transparently with any number of new types, it is called parametric polymorphism.
I'll point out that as much as I like wikipedia, it's an unedited, on-line encyclopedia.
I'll bite - I did a Google search just in case I'm the one that's missing something here. (It happens.) Google found these:
http://www.google.com/search?q=ad+hoc+polymorphism&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official
So before I dive in, explain to me what's new about describing polymorphism as "ad hoc"? When I first learned about polymorphism, compile-time and runtime typing there was no need for the "ad hoc" adjective. What is different when you add the term, in your opinion?
Is there a "sic hoc" polymorphism that is the antithesis of "ad hoc"?
I'm not being flip - I'm trying to understand here. I don't see the need for the adjective, and nobody's described anything that's different from the unadorned polymorphism that I know and love.
%
Well, the way I understood it you'd use ad-hoc polymorphism to describe things like what I mentioned about equals(). I've glanced at the first article google found, but I don't know jack about operator overloading in c/c++. So I'm not even sure if their definition of ad-hoc polymorphism matches the one I found.
I'm getting a bit confused though, since it seems one could reason that java only does ad-hoc polymorphism by saying that it's only polymorphic with respect to classes that actually declare/override a method, or the different types for which a method is overloaded. Would this mean that the only parametric polymorphism (using wikipedia definition here) in java is the assignment operator? :-|
Perhaps you could say that ad-hoc polymorphism is "programmed" polymorphism, as opposed to built-in polymorphism?
I've referred to Wikipedia again for the Latin, which states Ad hoc is a Latin phrase which means "for this [purpose]." My guess they use it to describe ad-hoc polymorphism because the programmer has to write the polymorphic behaviour himself, for a specific purpose.
Oh, and BTW, I've recently read an article that compared Wikipedia to Ecyclopedia Britannica. The article I read was offline, but a similar one seems to be http://www.futureofthebook.org/blog/archives/2005/12/nature_magazine_says_wikipedia.html. Anyway, it turned out that, at least for the portions they looked at, Wikipedia was generally no more erronous than the major encyclopedia.
> Well, the way I understood it you'd use ad-hoc
> polymorphism to describe things like what I mentioned
> about equals(). I've glanced at the first article
> google found, but I don't know jack about operator
> overloading in c/c++. So I'm not even sure if their
> definition of ad-hoc polymorphism matches the one I
> found.
Operator overloading is something different. Let's not confuse the issue, since you can't do it in Java. (I know the authors of Java did it for Strings, but they deliberately keep it out of our hands - too dangerous.)
>
> I'm getting a bit confused though, since it seems one
> could reason that java only does ad-hoc polymorphism
> by saying that it's only polymorphic with respect to
> classes that actually declare/override a method, or
> the different types for which a method is overloaded.
Where else is it polymorphic?
> Would this mean that the only parametric polymorphism
> (using wikipedia definition here) in java is the
> assignment operator? :-|
Assignment operator? Nope, it just follows the rules about assigning references.
> Perhaps you could say that ad-hoc polymorphism is
> "programmed" polymorphism, as opposed to built-in
> polymorphism?
It's all built-in. When you write code, your stuff is simply using what's built-in to the JVM.
> I've referred to Wikipedia again for the Latin, which
> states Ad hoc is a Latin phrase which means "for
> this [purpose]." My guess they use it to describe
> ad-hoc polymorphism because the programmer has to
> write the polymorphic behaviour himself, for a
> specific purpose.
No, I think the distinction is immaterial here. Polymorphism is a feature of object-oriented languages, not just Java. (C++, Smalltalk, etc. all have it.) When you write your code in one of these languages, you're not inventing anything. You're simply taking advantage of one feature that the languages give you.
I'm not buying the distinction. Polymorphism is enough, without the "ad hoc". I'm not convinced.
> Oh, and BTW, I've recently read an article that
> compared Wikipedia to Ecyclopedia Britannica. The
> article I read was offline, but a similar one seems
> to be
> http://www.futureofthebook.org/blog/archives/2005/12/n
> ature_magazine_says_wikipedia.html. Anyway, it turned
> out that, at least for the portions they looked at,
> Wikipedia was generally no more erronous than the
> major encyclopedia.
There have also been controversies lately about Wikipedia where falsehoods have been entered and later retracted after public outcry. That's the one advantage that EB has: With an editor, you have at least one layer that will perform due diligence to make sure that entries are factual. When the editor is gone, who checks?
Same difference between newspapers and blogs - no editor. It'll be interesting to see how the two play out in the future.
%
Well, I think the starting definition of polymorphism (as used in wikipedia) was meant to cover types in general. So, for them, the + operator in java would be polymorphic because it operates on different primitives type.
Then the + operator might be ad-hoc polymorphism, because it operates on different types, but not on all. The assignment operator might be parametric polymorphism, because it operates on all types.
Perhaps the difference is that one definition of polymorphism is "is applicable to different types", while another is "behaves differently for different types"?
Note that I'm still confused about this; these are vague thoughts, not crystallized opinions ;-)
> Well, I think the starting definition of polymorphism
> (as used in wikipedia) was meant to cover types in
> general. So, for them, the + operator in java would
> be polymorphic because it operates on different
> primitives type.
OK, I'll buy that.
> Then the + operator might be ad-hoc polymorphism,
> because it operates on different types, but not on
> all. The assignment operator might be parametric
> polymorphism, because it operates on all types.
But that's just because of the way that Java was designed. If we agreed that polymorphism is a concept that transcends Java, since we know that C++ and Smalltalk use it, and C++ does happen to allow operator overloading, it's just a question of whether or not you extend an operator to every object in your domain. Overloading an operator like "+" doesn't make sense for each and every class. But if it did, you could make it operate on all types. The polymorphic behavior would be unchanged, whether you restrict it or not.
> Perhaps the difference is that one definition of
> polymorphism is "is applicable to different types",
> while another is "behaves differently for different
> types"?
Still not buying it, but I see what you're saying. I think applicability and behavior are the same thing. I could extend a polymorphic operation to every class I write, and make the behavior for those nonsense cases be a no-op or throwing an OperationNotSupportedException. The scope of polymorphism doesn't change its underlying character.
> Note that I'm still confused about this; these are
> vague thoughts, not crystallized opinions ;-)
It's been a fine discussion for me. I've enjoyed it. I'm not sure that we'll end in agreement, but it's certainly been a pleasure. sincerely, %
>
> Operator overloading is something different. Let's
> not confuse the issue, since you can't do it in Java.
> (I know the authors of Java did it for Strings, but
> t they deliberately keep it out of our hands - too
> dangerous.)
>
I disagree. String does not use operator overloading. No more so than addition of doubles uses it. Perl and Basic both allow string concatenation as well as the C++ preprocessor. And no one claims that those are using operator overloading. The C++ string class specifically does use it however.
> > PS: There are many varied theoretical and technical
> > definitions of polymorphism.
>
> I disagree with this, too. Just one definition that
> I know of, and it's runtime typing. Please post
> examples of "many".
In java or in general?
Stroustrup seems to think that there are different types....my reply in the following thread posts his thoughts....
http://forum.java.sun.com/thread.jspa?threadID=698143&start=30
> Stroustrup seems to think that there are different
> types....my reply in the following thread posts his
> thoughts....
>
> http://forum.java.sun.com/thread.jspa?threadID=698143& start=30
I read that thread and I disagree. Bjarne used the term in several sections, but I didn't see different types - except for templates and "compile time polymorphism". That was a new idea to me.
And seeing how we've established that Java generics are NOT templates, does this apply equally well to Java?
It all still comes down to figuring out which function to call in the vtable by examining the type at runtime.
%
> It all still comes down to figuring out which
> function to call in the vtable by examining the type
> at runtime.
As I've mentioned a few posts ago, it seems there are definitions of polymorphism (e.g., wikipedia on parametrized polymorphism) that consider a methodpolymorphic if it takes a subtypable type as argument. As far as I can see, that doesn't necessarily involve virtual functions.
> > Stroustrup seems to think that there are different
> > types....my reply in the following thread posts
> his
> > thoughts....
> >
> >
> http://forum.java.sun.com/thread.jspa?threadID=698143&
> start=30
>
> I read that thread and I disagree. Bjarne used the
> term in several sections, but I didn't see different
> types - except for templates and "compile time
> polymorphism". That was a new idea to me.
Eh?
I was pointing out the post and not the thread.
Do you disagree with what Stroustrup said?
>
> And seeing how we've established that Java generics
> are NOT templates, does this apply equally well to
> Java?
>
I didn't consider that. I wasn't sure whether the previous comment was limited to java or not.
I wouldn't normally apply polymorphism to the use of generics nor C++ templates. I can however see where an broad definition might include them.
> It all still comes down to figuring out which
> function to call in the vtable by examining the type
> at runtime.
Which would be is disagreement with what Stroustrup said.
>
> Eh?
>
> I was pointing out the post and not the thread.
Yes.
> Do you disagree with what Stroustrup said?
Cheeky of me. 8) Obviously, BS knows what he's talking about - far be it from me to explain polymorphism to him. But I don't interpret these paragraphs as different definitions or flavors of polymorphism. It's just different ways to refer to the same thing - runtime typing.
> I didn't consider that. I wasn't sure whether the
> previous comment was limited to java or not.
>
> I wouldn't normally apply polymorphism to the use of
> generics nor C++ templates. I can however see where
> an broad definition might include them.
I think it's one broad definition. and it should transcend language, because it's not just a Java issue. Polymorphism is an O-O concept.
> Which would be is disagreement with what Stroustrup said.
I guess I'm disagreeing by your lights, but I say it's just a matter of interpretation. I don't see several separate flavors of polymorphism.
%
>
> > Do you disagree with what Stroustrup said?
>
> Cheeky of me.
Not necessarily. I haven't noted that he has done anything except C++. So his statements might not apply to OO in general.
>
> > I didn't consider that. I wasn't sure whether the
> > previous comment was limited to java or not.
> >
> > I wouldn't normally apply polymorphism to the use of
> > generics nor C++ templates. I can however see where
> > an broad definition might include them.
>
> I think it's one broad definition. and it should
> transcend language, because it's not just a Java
> issue. Polymorphism is an O-O concept.
Could be. It is a limitation though. I am not sure that just because C++ allows one to do it an compile time that it limits the role that it can play.
How would you classify Smalltalks ability to override the functionality of class (not instance)?
> Not necessarily. I haven't noted that he has done
> anything except C++. So his statements might not
> apply to OO in general.
He did Prolog before coming up with C++. I believe that was his original inspiration.
> Could be. It is a limitation though. I am not sure
> that just because C++ allows one to do it an compile
> time that it limits the role that it can play.
>
> How would you classify Smalltalks ability to override
> the functionality of class (not instance)?
I'm ignorant of Smalltalk, so I can't comment.
Does Lisp include the concept of polymorphism?
There's no concept of polymorphism in FORTRAN. 8)
You can roll your own in C if you use function pointers and your own vtable. Lots of work, but it can be done. It's just a question of whether the language supports a feature natively or not.
%
> Does Lisp include the concept of polymorphism?
Not sure of Lisp itself, but one of it's dialects, Scheme, does. So I'm assuming Lisp in general does also.
As far as I know, almost all OO and functional languages support polymorphism in one sense or another. I think most logical programming languages do, but my knowledge of those is fairly limited. I don't know much about other paradigms, and I'll leave the discusion of wether or not overloading in (pure) imperative languages is polymorphism to others also :-)
> > Of course that's how equals behaves. The JVM will
> > figure out that it should call your equals instead
> of
> > the java.lang.Object if you have one.
>
> That's not what he meant. His point was that the
> method behaves differently depending on the runtime
> type of the object passed to equals
... which is untrue...
> > > That's not what he meant. His point was that the
> > > method behaves differently depending on the
> > runtime
> > > type of the object passed to equals
> >
> > ... which is untrue...
>
> Care to explain?
duffymo already did
there is but one behaviour for the method Point.equals(Object), and it's defined by its one method body
RTTI is NOT polymorphism, it's its contrary IMHO
I mean, would THAT be polymorphism then ?
public class Object {
// blah
public boolean equals(Object o) {
if (o instanceof List) {
// loop through list elements and check if they're equal
} else if (o instanceof Integer) {
// check the intValues
} // and so on...
}
// blah
}
I see your point, though : Point.equals() does behave differently when passed a Point or an object of any other type, but that doesn't imply polymorphism is at work here
have you ever tried this:
public boolean equals(Object o)
{
if (o instanceof Object)
{
// will come here
}
else if (o instanceof anySubs)
{
// will it ever stop by here?
}
}
> >
> > How would you classify Smalltalks ability to override
> > the functionality of class (not instance)?
>
> I'm ignorant of Smalltalk, so I can't comment.
>
> Does Lisp include the concept of polymorphism?
>
Lisp and Perl and perhaps Basic(?) has the ability to execute code at runtime that is in a string variable. Obviously that can be dynamically controlled at runtime. Various SQL dialects do that as well.
So is that polymorphic?
As far as I can tell, not perse. It seems to me that it's just like having a built-in interpreter. If the compiler API in mustang is any good, we'll probably be able to fake it in java in a few months. But as far as I can see, it doesn't allow anything to operate on more types than before. So no, I wouldn't call it polymorphism.
> I see your point, though : Point.equals() does
> behave differently when passed a Point or an object
> of any other type, but that doesn't imply
> polymorphism is at work here
I see your point. But I can't agree.
I think most of the people here use the term polymorphism to indicate Java's implementation of it. In other words, they kind off equate it with runtime method dispatch. While I still haven't completely "grown" into the definitions and terminology, I can already tell this definition is too narrow for me.
I'll state one last time that polymorphism doesn't require virtual functions, inheritance, or any of that. Even a final (!) equals method is polymorphic according to some definitions.
Now I hear my beer she's calling
Off I am to fun and falling :-)
> Does Lisp include the concept of polymorphism?
Lisp has generic functions which allow polymorphic dispatch on the classes of all arguments to the function, instead of just the zeroth one (with . or -> syntactic sugar) as in Java and C++:
http://www.lisp.org/HyperSpec/Body/sec_7-6-2.html
> There's no concept of polymorphism in FORTRAN. 8)
Fortran 2003 supports class based polymorphism:
http://www.kcl.ac.uk/kis/support/cit/fortran/john_reid_new_2003.pdf
Pete
> Lisp has generic functions which allow polymorphic
> dispatch on the classes of all arguments to the
> function, instead of just the zeroth one (with . or
> -> syntactic sugar) as in Java and C++:
I'm not sure I understand what you mean? Would you mind giving an example?
> > Does Lisp include the concept of polymorphism?
>
> Lisp has generic functions which allow polymorphic
> dispatch on the classes of all arguments to the
> function, instead of just the zeroth one (with . or
> -> syntactic sugar) as in Java and C++:
>
> http://www.lisp.org/HyperSpec/Body/sec_7-6-2.html
>
> > There's no concept of polymorphism in FORTRAN. 8)
>
> Fortran 2003 supports class based polymorphism:
>
> http://www.kcl.ac.uk/kis/support/cit/fortran/john_reid
> _new_2003.pdf
>
>
> Pete
I never even got to FORTRAN 90. All my experience is with FORTRAN 77. 8)
I thought that FORTRAN 90 was starting to look more like C. Are you saying that FORTRAN 2003 is morphing into C++?
What's the point? 8)
%
> Errrr...what's the point of C#?
Very big difference.
C# Microsoft's answer to Java. Business drove it. FORTRAN is more of an evolving standard.
C# did to Java what Java did to C++: take lessons learned and improve on them. FORTRAN seems to be taking things from other languages that were never part of its original design and incorporating them.
My "point" is this: FORTRAN's great claim to fame in scientific computing was its speed. It would blow even C away in timing comparisons, because walking through an array to perform computations was so fast.There was no malloc or free and no pointer arithmetic involved.
If FORTRAN takes on a bunch of stuff that makes it more like C/C++ but loses that blazing speed advantage, why wouldn't I just write my apps in C/C++ from now on? I don't care about object-orientation in FORTRAN; I just want LINPACK to run like a bat out of hell so I can solve million DOF linear algebra problems quickly.
%
> > Errrr...what's the point of C#?
>
> Very big difference.
>
> C# Microsoft's answer to Java. Business drove it.
> FORTRAN is more of an evolving standard.
>
> C# did to Java what Java did to C++: take lessons
> learned and improve on them.
What part specifically is an improvement?
Although it conceptually it could run on more than one platform the reality is that it doesn't right now and quite realistically I don't see it ever happening in any way that is meaningful.
I don't really care for namespaces versus packages.
Assemblies really annoy me compared to jars. Solving the dll problem has made code maintenance a nightmare compared to java and even to C++.
Properties are subject to abuse.
The documentation tends to be annoying in a number of ways.
Some of the Net libraries particularily with the more complex stuff is very difficult to figure out. For example how to map values between C# and windows libraries (which would be JNI in java.) And how to 'correctly' load a complex (w3 even) schema so one can validate xml against it.
How confident do you feel in ports of things like jboss, hibernate, log4n, etc? Myself I think log4net is fairly stable, but I suspect many others will need quite a bit of time to catch up.
The 'partial' keyword is kind of neat. The documentation gives two reasons to justify it. One is what I use it for - adding manual code to generated code. The other reason leads directly to the Anti-Pattern God/Blob. Which isn't a good thing.
Not that is significantly worse than java but I just don't see where the improvement part comes in.
I can see where MS might think there is a significant improvement - because Sun can't tell them what to do with it. But I would say that is an improvement in general.
> If FORTRAN takes on a bunch of stuff that makes it
> more like C/C++ but loses that blazing speed
> advantage, why wouldn't I just write my apps in C/C++
> from now on? I don't care about object-orientation
> in FORTRAN; I just want LINPACK to run like a bat out
> of hell so I can solve million DOF linear algebra
> problems quickly.
I'd agree with the sentiment; from what of the Fortran 2003 literature I've read, they intend it to be very simple OO but only applied where needed (much as the overhead in recursion is only encountered if you mark a Fortran 90 function as recursive), and they very much did't want it to become C++. But I can't really see a little bit of OO making much of a difference to most Fortran programs in the world.
Pete
can you please start your own thread and not resurrect six month old topics?
can you please read something about java to learn a bit more about polymorphism before you come here and ask?
poly = many, morph = form, so polymorphism means "many forms". In Java, it's when the runtime type that a reference points to can give different behavior. It's related to inheritance.
the classic example is a Shape hierarchy: Circle, Square, Rectangle, etc., all subclassing an interface Shape:
public interface Shape
{
double getArea();
}
Each class calculates area in their own way, so if you iterate through a List of Shapes each one will do the calculation properly.
List<Shape> shapes = new ArrayList<Shape>();
shapes.add(new Circle());
shapes.add(new Square());
shapes.add(new Rectangle());
for (Shape shape : shapes)
{
System.out.println("area: " + shape.getArea());
}
%