Talk:Polymorphism: Difference between revisions
→Circle is a Point?
(→Fortran: new section) |
|||
| (3 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 83 ⟶ 86:
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.)
| |||