Talk:Polymorphism: Difference between revisions
→Circle is a Point?
(How to change, and another suggestion) |
|||
| (4 intermediate revisions by 3 users not shown) | |||
Line 1:
==Circle is a Point?==
Hi, I think there's a big conceptual error in the code examples: Almost all of them derive a Circle class from a Point class. This is IMHO conceptually wrong; derivation would mean that a circle ''is-a'' point, which is clearly not the case. You wouldn't normally pass circles to functions expecting points (say, a function returning the straight line through two points).
:''It's probably worth noting that the center of a circle is a point. (This issue was treated in some of the sample code in this section, but was not even touched on in the surrounding discussion. That said, a relevant underlying issue might be that polymorphism has little to do with abstraction.) --[[User:Rdm|Rdm]] 13:59, 26 October 2011 (UTC)''
The task, as described, doesn't demand to make that error (although I suspect that whoever wrote that task had this wrong derivation in mind).
Line 79 ⟶ 82:
Porsche Pinto</pre>
:There could be a "start" method in each class. For Car, it could print "vroom vroom", Porsche prints "go, baby, go!", and Pinto prints "clunk clunk". Then make a collection of Car objects (one Car, one Pinto, and one Porsche) and call the start method on each one for proof. Is that an OK idea or is it too complex?--[[User:Mwn3d|Mwn3d]] 16:31, 3 November 2008 (UTC)
== Fortran ==
I've removed omit from Fortran since this task can be implemented a lot better than the C code example. Using modules, overloading and derived types Fortran "seems" a lot more object oriented than C... Moreover... I've read from wikipedia [[wp:Type polymorphism]] that polymorphism is not necessarily OOP-related, even though the task talks about "classes"; I think Fortran can have ''easily'' ad-hoc polymorphism (but I am always unsure about any formal definition of a language feature...) --[[User:ShinTakezou|ShinTakezou]] 09:40, 17 July 2009 (UTC)
Second thought: Fortran (2003) can polymorphism and more; even Fortran95 could, with quirks... I am downloading the Intel Fortran compiler for noncommercial usage right now... if it works, I'll try to write full Fortran 2003 code... (GNU Fortran implements some features already) --[[User:ShinTakezou|ShinTakezou]] 10:19, 17 July 2009 (UTC)
The Fortran example is wrong: If the components ''x'', ''y'' and ''r'' are PRIVATE, they may not be used in a structure constructor (<tt>point(0.0,0.0)</tt>); or in the words of the current ISO Fortran 2008 standard: "C495 (R455) The type name and all components of the type for which a component-spec appears shall be accessible in the scoping unit containing the structure constructor." GNU Fortran (gfortran) correctly errors out while Intel's ifort 11.1 accepts it by default. Solution 1: Use
p = point() ! instead of "point(2.0d0, 3.0d0)"; uses the default initialization to 0.0
p%set_x (2.0d0)
p%set_y (3.0d0)
Solution 2: Use a constructor, i.e. a generic interface with the same name as the derived type:
interface point
module procedure set_point
end interface point
type(point) function set_point(x,y)
real(8), intent(in) :: x, y
set_point%x = x
set_point%y = y
end function set_point
Solution 3: Remove the PRIVATE attribute from the component definition.
Solution 1 works, but is a bit ugly. ("set_point(x,y)" would already be better); solution 3 also works, but makes the components world read/writable. Solution 2 is more elegant, but you need a rather new compiler; I think ifort 12 will support it - ifort 11.1 is not sufficient and gfortran also cannot compiler it yet. Final note: <tt>REAL(8)</tt> is not standard conform as the kind numbers are not defined. One could use <tt>integer, parameter :: dp = kind(0.0d0)"</tt> and then <tt>REAL(dp)</tt>. (Though, as REAL(8) is widely used, most compilers support it - either by default or with a flag.)
| |||