Home > Archive > Fortran > September 2005 > OOP with FORTRAN
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi,
I am trying to understand the concept of Object Oriented Programming
(OOP) with fortran. As far as I know, there is only 1 book by Ed Akin
on this topic and lots of them in C++.
In any of the references (C++ and FORTRAN) on OOP, it is always that
this concept is related with the "type" variable in FORTRAN (I can't
remember what it is in C++).
Up to now, I do not really understand what this OOP means. Why all the
references provide examples with "type". Is it still called OOP if it
is not with "type" , etc.? Lot of questions in my head concerning this
OOP.
To make it simple, suppose I have the following code (below). Can we
call it OOP programming? If it is not, why? Can somebody explain what
an OOP really is and give a very simple example (like the below, if
possible) of it in FORTRAN?
Thanks in advance.
Regards,
Irfan
!----------------------
program main
use var
use calculation
x=10.
y=20.
call addition
call substraction
print*,'x=',x
print*,'y=',y
print*,'x+y=',w
print*,'x-y=',z
end program main
module var
real :: x,y,w,z
end module var
module calculation
use var
contains
subroutine addition
w=x+y
end subroutine addition
subroutine substraction
z=x-y
end subroutine substraction
end module calculation
| |
| Erik Edelmann 2005-09-21, 7:00 pm |
| On 2005-09-21, kis <kisitanggang@gmail.com> wrote:
> Hi,
>
> I am trying to understand the concept of Object Oriented Programming
> (OOP) with fortran. As far as I know, there is only 1 book by Ed Akin
> on this topic and lots of them in C++.
>
> In any of the references (C++ and FORTRAN) on OOP, it is always that
> this concept is related with the "type" variable in FORTRAN (I can't
> remember what it is in C++).
>
> Up to now, I do not really understand what this OOP means.
One problem with understanding OOP is that it isn't an exactly defined
concept. A list of things it can be is found here:
http://www.paulgraham.com/reesoo.html. (It is written by someone who
apperantly doesn't like OOP very much. Personally I think OOP is OK, but
maybe it is just because I'm not a Lisp programmer :-).
Erik
| |
| glen herrmannsfeldt 2005-09-21, 7:00 pm |
| kis wrote:
(snip)
> Up to now, I do not really understand what this OOP means. Why all the
> references provide examples with "type". Is it still called OOP if it
> is not with "type" , etc.? Lot of questions in my head concerning this
> OOP.
There are object oriented languages which encourage, and have features
to help, writing object oriented programs, but one can write OO in
other languages, and write non-OO in C++.
> To make it simple, suppose I have the following code (below). Can we
> call it OOP programming? If it is not, why? Can somebody explain what
> an OOP really is and give a very simple example (like the below, if
> possible) of it in FORTRAN?
> !----------------------
> program main
> use var
> use calculation
> x=10.
> y=20.
> call addition
> call substraction
> print*,'x=',x
> print*,'y=',y
> print*,'x+y=',w
> print*,'x-y=',z
> end program main
>
> module var
> real :: x,y,w,z
> end module var
>
> module calculation
> use var
> contains
> subroutine addition
> w=x+y
> end subroutine addition
>
> subroutine substraction
> z=x-y
> end subroutine substraction
> end module calculation
I would say not. The w and z being, in some sense, global
(along with x and y).
There should be a routine supplying the arguments that will be
used for addition and subtraction, and another to retrieve the
results.
The main program might look like:
x=10
y=20
call suuplyoperands(obj,x,y)
call addition(obj)
call subtraction(obj)
call getresults(obj,w,z)
print "x+y=",w
In this case, obj might be a structure (derived type) or
it might just be an ordinary variable or array.
Each call should have an argument which is the object that
it is operating on. Objects should be changed or examined only
by called routines, never by directly accessing their members.
-- glen
| |
| Clive Page 2005-09-21, 7:00 pm |
| In message <1127326605.248092.139490@g49g2000cwa.googlegroups.com>, kis
<kisitanggang@gmail.com> writes
>I am trying to understand the concept of Object Oriented Programming
>(OOP) with fortran. As far as I know, there is only 1 book by Ed Akin
>on this topic and lots of them in C++.
This website
http://www.cs.rpi.edu/~szymansk/oof90.html
has quite a lot of good stuff on the subject.
--
Clive Page
| |
| Michael Metcalf 2005-09-21, 7:00 pm |
|
"kis" <kisitanggang@gmail.com> wrote in message
news:1127326605.248092.139490@g49g2000cwa.googlegroups.com...
> Hi,
>
> I am trying to understand the concept of Object Oriented Programming
> (OOP) with fortran. As far as I know, there is only 1 book by Ed Akin
> on this topic and lots of them in C++.
>
Note that our "Fortran 95/2003 Explained" describes the OO features of
Fortran 2003. We hope that there'll soon be a compiler with which we can
check our examples :-(.
Regards,
Mike Metcalf
| |
| beliavsky@aol.com 2005-09-21, 9:57 pm |
| Michael Metcalf wrote:
> "kis" <kisitanggang@gmail.com> wrote in message
> news:1127326605.248092.139490@g49g2000cwa.googlegroups.com...
> Note that our "Fortran 95/2003 Explained" describes the OO features of
> Fortran 2003. We hope that there'll soon be a compiler with which we can
> check our examples :-(.
Your book describes the OOP features of Fortran in a chapter, but there
is insufficient space to provide a lot of motivation or examples. I
wonder what general books you or others would recommend for Fortranners
interested in OOP. It's natural to look at one of the books on C++ for
scientific computing, but Fortran 90+ already has the functionality of
the matrix and vector classes they describe.
| |
|
| I read this book. It's great. I like it. But still my question remains
unanswered. Is the small/simple program that I posted an OOP one?
Well, one lister said it is NOT. And instead revised it a bit with
"obj" (see below). It seems to me both are still similar?????
Excerpted from previous comment:
:
:
The main program might look like:
x=10
y=20
call suuplyoperands(obj,x,y)
call addition(obj)
call subtraction(obj)
call getresults(obj,w,z)
print "x+y=",w
:
:
Thanks,
Irfan
| |
| Richard Maine 2005-09-22, 3:57 am |
| In article <1127359612.449768.91950@z14g2000cwz.googlegroups.com>,
"kis" <kisitanggang@gmail.com> wrote:
> I read this book. It's great. I like it. But still my question remains
> unanswered. Is the small/simple program that I posted an OOP one?
If you can ask the question, then you don't yet understand. :-(
Not that I mean this in a negative way, as many people don't understand.
What I mean is that it is not a simple yes/no matter. One cannot
meaningfully ask "Is this an OOP program? Yes or no?" If you try to ask
that, you will sometimes get even the best experts disagreeing.
There are principles of object orientation. You can follow those
principles to a greater or lesser degree. If you follow them a lot, you
can be said to have an object oriented program. If you don't follow them
at all, then you don't. And there are infinite shades of gray in between.
That question is somewhat like asking whether a given essay is well
written. For some essays, you can pretty clearly answer yes. For others,
you can pretty clearly answer no. But most real samples are somewhere in
between and neither "yes" nor "no" is a very meaningful answer.
If you want to learn the principles of object orientation, you need to
study those principles - not just ask whether a given program is or is
not object oriented. You aren't likely to get there by going in that
direction.
I'll add that object orientation shows up more in larger programs than
in small ones. It is awfully hard to give a program in as few lines as
the one you have and meaningfully show what object orientation is about.
That's partly because object orientation has a lot to do with the
relationships of different types of objects. That means you need
multiple objects of multiple kinds in order to really see much. I might
draw a parallel to asking whether a given Fortran statement is well
structured or not. You need more than just a single statement to say.
And while there are some applications where object orientation fits
well, there are others where it is just plain silly. I think you will
find that a large majority of people will agree that object orientation
doesn't help much in terms of basic arithmetic operations. (You won't
find 100% agreement on anything relating to object orientation, but I
think you'll find that at least a solid majority agree with that). So
trying to use basic arithmetic to illustrate object orientation is
pretty much doomed to failure; after seeing it, you'd probably say "what
a roundabout, silly way to do things". And you'd be right (in my
opinion). That's because it is the wrong application.
I don't think I'll try to do much in this post to explain it because
1) the post is long enough already
2) I'd probably not do a very good job on the fly like this
3) Its a bit late and I'm getting tired (which would make the previous
point worse).
4) This isn't the best medium for it. Much better to get a good book or
other reference on the subject. You'll get a much more organized and
thoughtful presentation than you'll get in the newsgroup.
| |
| glen herrmannsfeldt 2005-09-22, 3:57 am |
| Richard Maine wrote:
> In article <1127359612.449768.91950@z14g2000cwz.googlegroups.com>,
> "kis" <kisitanggang@gmail.com> wrote:
[color=darkred]
> If you can ask the question, then you don't yet understand. :-(
> Not that I mean this in a negative way, as many people don't understand.
> What I mean is that it is not a simple yes/no matter. One cannot
> meaningfully ask "Is this an OOP program? Yes or no?" If you try to ask
> that, you will sometimes get even the best experts disagreeing.
Well, I think for a very small program it is close to yes/no,
but otherwise I agree.
> There are principles of object orientation. You can follow those
> principles to a greater or lesser degree. If you follow them a lot, you
> can be said to have an object oriented program. If you don't follow them
> at all, then you don't. And there are infinite shades of gray in between.
I put "object oriented programming" into Google with the "'s, and the
first entry seems to be from Sun. The examples are Java, but at
least it tries to explain it.
http://java.sun.com/docs/books/tuto.../practical.html
One thing, though, is that it tends to be done using GUI object,
which makes it seem like GUI programming and OO programming are
necessarily connected.
(snip)
> I'll add that object orientation shows up more in larger programs than
> in small ones. It is awfully hard to give a program in as few lines as
> the one you have and meaningfully show what object orientation is about.
> That's partly because object orientation has a lot to do with the
> relationships of different types of objects. That means you need
> multiple objects of multiple kinds in order to really see much. I might
> draw a parallel to asking whether a given Fortran statement is well
> structured or not. You need more than just a single statement to say.
Well, also for structured programming. A program that is a few
statements long can't be very unstructured. Still, if it uses
structured language constructs you might call it structured.
> And while there are some applications where object orientation fits
> well, there are others where it is just plain silly. I think you will
> find that a large majority of people will agree that object orientation
> doesn't help much in terms of basic arithmetic operations. (You won't
> find 100% agreement on anything relating to object orientation, but I
> think you'll find that at least a solid majority agree with that). So
> trying to use basic arithmetic to illustrate object orientation is
> pretty much doomed to failure; after seeing it, you'd probably say "what
> a roundabout, silly way to do things". And you'd be right (in my
> opinion). That's because it is the wrong application.
One that I always thought was a little silly is the Java classes
for sending UDP packets. UDP is connectionless, so there is no need
for an object to maintain the status of the connection. There is
one to create a UDP packet object, one to put data in the object,
and one to send it. There really isn't much else to do with UDP,
but they wanted to fit it into the OO framework.
OO programming tends to use routines with names like SetSomething and
GetSomething, where you setup the parameters for whatever it is that
you are trying to do with the Set... method, and read wit the Get... method.
This allows the actual data structures to be hidden from the user, and
they can easily be changed if needed without changing the API
(programmer interface).
As for your example, if you used a subroutine to pass the x and y
values, even without the obj parameter that I added, and another to
retrieve w and z, you are most of the way there. The problem, though,
is that it doesn't scale. You can't do more than one of them at once.
The obj parameter allows one to specify which of multiple similar
objects it applies to.
-- glen
| |
|
| Thanks for spending some time to explain, although it makes me even
more  :(
I believe there are simple ways of explaining what an OOP is. The best
one is through a very simple example (see examples program in Ed Akin).
Whether or not it is a silly application like you said, that's a
different story. Through a simple implementation of OOP, we hope we
will easily see the concept of 1. encapsulation, 2. polymorphism, and
3. inheritance. These 3 properties are not IMPOSSIBLE to see even in a
very simple arithmetic-OOP code. In many C++ books, the authors explain
OOP concept with simple application.
| |
|
| Richard Maine wrote:
> In article <1127359612.449768.91950@z14g2000cwz.googlegroups.com>,
> "kis" <kisitanggang@gmail.com> wrote:
>
> I'll add that object orientation shows up more in larger programs than
> in small ones. It is awfully hard to give a program in as few lines as
> the one you have and meaningfully show what object orientation is about.
>
> And while there are some applications where object orientation fits
> well, there are others where it is just plain silly. I think you will
> find that a large majority of people will agree that object orientation
> doesn't help much in terms of basic arithmetic operations.
Thanks for spending some time to explain, although it makes me even
more :(
I believe there are simple ways of explaining what an OOP is. The best
one is through a very simple example (see examples program in Ed Akin).
Whether or not it is a silly application like you said, that's a
different story. Through a simple implementation of OOP, we hope we
will easily see the concept of 1. encapsulation, 2. polymorphism, and
3. inheritance. These 3 properties are not IMPOSSIBLE to see even in a
very simple arithmetic-OOP code. In many C++ books, the authors explain
OOP concept with simple application.
| |
| Arjen Markus 2005-09-22, 3:57 am |
| Examples like complex numbers hardly count: they show how to use
operator overloading in C++, but it is tough to come up with a
meaningful hierarchy of arithmetic objects (in the mathematical sense).
Of course, you can think of the integers, the rationals, the quadratic
fields, ... but how relevant is that to the kind of programs most OOP
proponents think of?
Then again what is essential to OOP is far from clear: a C++ adept will
stress very different things than someone inclined to Java or Eiffel or
CLOS or ...
The main thing to learn from OOP is that you can hide the details of a
particular implementation (data hiding) so that you can do different
things under the covers without affecting the using programs. And that
sort "encapsulation" is quite possible
and even easy with Fortran 90 ...
Regards,
Arjen
| |
| Jan Vorbrüggen 2005-09-22, 3:57 am |
| > Through a simple implementation of OOP, we hope we
> will easily see the concept of 1. encapsulation, 2. polymorphism, and
> 3. inheritance. These 3 properties are not IMPOSSIBLE to see even in a
> very simple arithmetic-OOP code. In many C++ books, the authors explain
> OOP concept with simple application.
For one, many authors fail, and some of them miserably, in explaining what
the concepts of object orientation are, let alone using a simple application,
which is very difficult to do well for the reason Richard mentioned.
For a second, even the experts do not agree that all of those three concepts
you mention have something to do with OOP, and if so how much of them are
good or bad. Encapsulation is probably not subject to much debate, but poly-
morphism to some, inheritance to a lot, and multiple inheriticance is a
religious issue much worse than endianess.
Jan
| |
| glen herrmannsfeldt 2005-09-22, 7:57 am |
| Jan Vorbrüggen wrote:
[color=darkred]
[color=darkred]
> For one, many authors fail, and some of them miserably, in explaining what
> the concepts of object orientation are, let alone using a simple
> application,
> which is very difficult to do well for the reason Richard mentioned.
> For a second, even the experts do not agree that all of those three
> concepts you mention have something to do with OOP,
> and if so how much of them are good or bad.
> Encapsulation is probably not subject to much debate,
I agree. I believe this is the primary OOP indication, though
I forgot the word in my previous explanations. You shouldn't,
though the implementation may not stop you, look directly at
internal variables.
> but polymorphism to some, inheritance to a lot,
To me these are features of some implementations, but not part of
the definition. They may improve it, but they aren't required.
Maybe some would say quality of implementation issues.
> and multiple
> inheriticance is a religious issue much worse than endianess.
-- glen
| |
| Carlie J. Coats 2005-09-22, 7:57 am |
| glen herrmannsfeldt wrote:
> kis wrote:
>
> (snip)
>
>
>
> There are object oriented languages which encourage, and have features
> to help, writing object oriented programs, but one can write OO in
> other languages, and write non-OO in C++.
Let me commend to you Bertrand Meyer's classic book _Object-Oriented
Software Construction_, which pushes Meyer's Eiffel O-O language, but
(1) does an excellent job of explaining the issues; and (2) has sections
on object oriented programming in other languages, including Fortran.
See
http://www.amazon.com/exec/obidos/t...=books&n=507846
--
Carlie J. Coats, Jr. carlie.coats@baronams.com
Environmental Modeling Center carlie_coats@ncsu.edu
Baron Advanced Meteorological Systems, LLC
| |
| Pierre Asselin 2005-09-22, 6:58 pm |
| kis <kisitanggang@gmail.com> wrote:
> Thanks for spending some time to explain, although it makes me even
> more :(
The question you asked has an enormous scope.
> I believe there are simple ways of explaining what an OOP is.
Maybe. Personally, I think a two-semester college class would
be about right.
--
pa at panix dot com
| |
|
| Jan Vorbr=FCggen wrote:
>
> good or bad. Encapsulation is probably not subject to much debate, but po=
ly-
> morphism to some, inheritance to a lot, and multiple inheriticance is a
Absolutely, this is what I like with OOP (previously Arajen called it
data hiding). And to explain this concept with very simple example (in
FORTRAN) does not require 2 semesters of OOP college class (Pierre).
| |
| Richard E Maine 2005-09-22, 6:58 pm |
| In article <Psydnbmfwqma2q_eRVn-oQ@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> http://java.sun.com/docs/books/tuto.../practical.html
>
> One thing, though, is that it tends to be done using GUI object,
> which makes it seem like GUI programming and OO programming are
> necessarily connected.
Yes. For the longest time, I completely failed to "get" object
orientation, partly because I just could not see the connections between
the examples typically used and anything I would want to do in my own
programs. Yes, I know that a dog is a kind of an animal and that a
Labrador is a kind of a dog, but I'm afraid it just doesn't inspire me
as having much to do with my programs. I kept figuratively falling
asleep in listening to explanations of OO.
I can point to exactly when this changed for me.
John Cuthbertson gave a presentation on OO at a joint J3/WG5 meeting in
Vegas several years ago when the features for f2003 were first being
debated. His presentation put it in terms of Fortran constructs that
allowed me to get a concrete understanding of at least a few of the
basics. I realized that, not only did this have relevance to my own
applications, but I had been using some of the object oriented
principles for over a decade without knowing that here were terms for
that style of organization. It had just seemed like a way to organize
some parts of some of my applications.
John's pitch did gave me terms for things I was already doing, plus a
few extra ideas further along those paths. And it enthused me to realize
that a compiler could actually help instead of hinder such organization.
That's when I became a fan of adding some object-oriented constructs to
Fortran (but not going overboard as some people wanted to in my opinion;
I wanted to add stuff that seemed to fit in Fortran - not redo the whole
language around OO.) I had been "fighting" with the language on a few
issues and as soon as I saw part of John's pitch, I realized that
addressed exactly the point I had been "fighting" over.
(I had a derived type and I wanted to add more components to it, but
different components for different cases. For a while I "faked" it by
using TRANSFER tricks to sort of get the effect of a C void pointer,
which could point to different types of "add-on" data for different
cases. Gee was that a mess. And it broke compilers left and right. I
finally switched to a different hack. But inheritance would do it so
much more cleanly. And dynamic dispatch of methods would be "icing on
the cake" for another thing I was fighting with.)
Perhaps I'll try to put together my version of an explanation some day
(not today). No, I don't think it takes a 2-quarter grad course or a
whole book, at least to get the basics. But it does take more thought
and organization than I'm going to put into a usenet posting. If I'm
going to take the time to do a decent job of an explanation, (immodestly
assuming that I can) then I'll put it in some form where it has a little
more lasting value.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Walter Spector 2005-09-22, 6:58 pm |
| kis wrote:
> I am trying to understand the concept of Object Oriented Programming
> (OOP) with fortran. As far as I know, there is only 1 book by Ed Akin
> on this topic and lots of them in C++.
Akins book tries to fill a void in the Fortran bookshelf.
I think there is room for another...
> In any of the references (C++ and FORTRAN) on OOP, it is always that
> this concept is related with the "type" variable in FORTRAN (I can't
> remember what it is in C++).
>
> Up to now, I do not really understand what this OOP means. Why all the
> references provide examples with "type". Is it still called OOP if it
> is not with "type" , etc.? Lot of questions in my head concerning this
> OOP.
Derived types are the basic way to define objects. Then you need to
write 'methods' to operate on those objects.
Fortran-95 is missing some of the syntactic sugar that languages like
Java and C++ have for tightly integrating methods with types. So one
has to write in a more conventional manner to implement the concepts.
> To make it simple, suppose I have the following code (below). Can we
> call it OOP programming? If it is not, why?
It isn't structured right. For a first step, try something like
the following:
module var_module
! Define a derived type and some associated methods.
implicit none
type var
real :: val = 0.0
end type
! Define generic names, so that the callers are not bound
! to a specific type.
interface getval
module procedure getval_var
end interface
interface setval
module procedure setval_var
end interface
interface addval
module procedure addval_var
end interface
interface subval
module procedure subval_var
end interface
contains
! By convention, the target 'object' is always the first dummy arg in each method.
function getval_var (me)
type(var), intent(in) :: me
real :: getval_var
getval_var = me%val
end function
subroutine setval_var (me, value)
type(var), intent(inout) :: me
real, intent(in) :: value
me%val = value
end subroutine
subroutine addval_var (me, y)
type(var), intent(inout) :: me
type(var), intent(in) :: y
me%val = me%val + y%val
end subroutine
subroutine subval_var (me, y)
type(var), intent(inout) :: me
type(var), intent(in) :: y
me%val = me%val - y%val
end subroutine
end module
program main
use var_module
implicit none
type (var) :: w, x, y, z ! Instances of objects of type 'var'
call setval (x, 10.)
call setval (y, 20.)
call setval (w, getval (x))
call addval (w, y)
print *, 'x+y =', getval (w)
call setval (z, getval (x))
call subval (z, y)
print *, 'x-y =', getval (z)
end program
Walt
-...-
Walt Spector
(w6ws att earthlinkk dott nett)
| |
| E. Robert Tisdale 2005-09-22, 6:58 pm |
| kis wrote:
> I am trying to understand
> the concept of Object Oriented Programming (OOP) with Fortran.
> As far as I know, there is only 1 book by Ed Akin on this topic
A reference please.
> and lots of them in C++.
>
> In any of the references (C++ and Fortran) on OOP,
> it is always that this concept is related with the "type" variable in Fotran
> (I can't remember what it is in C++).
A User Defined Type (UDT) is introduced into a Fortran 90/95/03 program
using the *type* keyword and into C++ using either *struct* or *class*.
> Up to now, I do not really understand what this OOP means.
> Why all the references provide examples with "type".
> Is it still called OOP if it is not with "type" , etc.?
> Lot of questions in my head concerning this OOP.
>
> To make it simple, suppose I have the following code (below).
> Can we call it OOP programming?
No.
> If it is not, why?
> Can somebody explain what an OOP really is
> and give a very simple example (like the below, if possible) of it in FORTRAN?
> !----------------------
> program main
> use var
> use calculation
> x = 10.
> y = 20.
> call addition
> call substraction
> print*,'x = ', x
> print*,'y = ', y
> print*,'x + y = ', w
> print*,'x - y = ', z
> end program main
>
> module var
> real:: x, y, w, z
> end module var
>
> module calculation
> use var
> contains
> subroutine addition
> w = x + y
> end subroutine addition
>
> subroutine substraction
> z = x - y
> end subroutine substraction
> end module calculation
Object Oriented Programming (OOP)
was invented by Ole-Johan Dahl and Kristen Nygaard
http://heim.ifi.uio.no/~kristen/FOR...F_OO_start.html
and implemented in their Simula computer programming language.
The term "object oriented" was coined much later by Alan Kay
http://www.smalltalk.org/articles/a..._20040731a.html
to describe the Smalltalk computer programming language
and *not* to classify computer programming languages.
Bjarne Stroustrup
http://www.research.att.com/resourc...cles/oopsla.pdf
specifies support for three language features:
1. [Data] Abstraction - providing some form of classes and objects.
2. Inheritance - providing the ability
to build new [data] abstractions out of existing ones.
3. Run-time polymorphism - providing some form of run-time binding
[of virtual function invocations to actual function invocations].
that can be used to discriminate between computer programming languages
that are object oriented and those that are not.
These discriminators are not unique
and other experts may use a different set of discriminating features
but Stroustrup is obviously trying to capture the "essence"
of object oriented computer programming languages in his choice.
So the definition of an object oriented computer programming language
is relatively straight-forward but classifying programs and programmers
is a little more problematic.
You can write "object-oriented" programs in languages that do not
support any of the features listed above.
In Fact, it is difficult to imagine how a programmers can be successful
unless they are "object-oriented".
An object-oriented design is evident in Jack Dongarra's
Application Program Interface (API) for BLAS and LAPACK.
The problem is that Fortran 77 does *not* support any kind
of data abstraction -- no UDTs to encapsulate vector and matrix objects
so he was obliged to improvise with Fortran 77 arrays
and define subprogram interfaces with long argument lists.
Fortran 90 addressed this deficiency by adding derived types
(and extending [sub]array types to more closely represent
[sub]vectors, [sub]matrices and higher order [sub]tensors)
but Fortran 90 did *not* provide support for inheritance
or run-time polymorphism.
Note that
programs implemented in an object-oriented computer programming language
need not use any of the so-called object-oriented features.
Are such programs "object-oriented"?
Many good programmers will say that they are not.
Also, some programmers refer to object-oriented programs
that are not written in an object-oriented programming language
as "object-based" computer programs.
Most object-oriented programmers use the term as a synonym for
"good programming practice" -- meaning that OOP subsumes
all of structured programming for example.
Some programmers use the term in reference to programs
that actually make explicit use of run-time polymorphism
which is difficult to implement effectively before Fortran 03.
Objects are data objects -- constants or variable that are
(or at least could be) represented by computer memory.
They do *not* contain methods [subprograms].
But they may contain a reference to a jump table
of subprograms which may be appropriately applied to the object.
The bottom line is
"Don't assume that
people know what *you* mean by object-oriented."
| |
| glen herrmannsfeldt 2005-09-22, 6:58 pm |
| E. Robert Tisdale wrote:
(snip)
> Note that
> programs implemented in an object-oriented computer programming language
> need not use any of the so-called object-oriented features.
> Are such programs "object-oriented"?
> Many good programmers will say that they are not.
> Also, some programmers refer to object-oriented programs
> that are not written in an object-oriented programming language
> as "object-based" computer programs.
I wasn't so convinced or Richard Maine's continuum of object
orientedness yesterday, but this one makes it more obvious.
In Java, arrays are in the Object class, and some objects
are required for all I/O operations, so it would be pretty
hard to write Java without any objects.
One thing that still bothers me about many object oriented
programming systems is the high rate of memory allocation and
deallocation. I don't believe that is required to be OO, but
it is very common.
Tight loops where each iteration creates one or more objects,
which are then destroyed by the end of the loop can be pretty
expensive. I have sometimes written Java code that reuses
an object inside a loop, though that might make it a little
bit less object oriented, at least as viewed by some.
-- glen
| |
| Arjen Markus 2005-09-23, 3:58 am |
| That is partly due to the particular implementation of that language
and partly due to coding practices: people programming in languages
like C++ and Java tend use variables with as tight a scope as possible,
so they declare their variables inside the loops. This means the
creation and destruction of the objects for each loop, unless the
compiler knows that it can reuse the memory.
Regards,
Arjen
| |
| Pierre Asselin 2005-09-23, 7:00 pm |
| kis <kisitanggang@gmail.com> wrote:
> Jan Vorbr?ggen wrote:
[color=darkred]
> Absolutely, this is what I like with OOP (previously Arajen called it
> data hiding). And to explain this concept with very simple example (in
> FORTRAN) does not require 2 semesters of OOP college class (Pierre).
Of course not. Encapsulation would be covered in the first w
of class. It would be recurring feature for the rest of the course.
Yeah I agree, maybe it's a one-semester class, including (in the US)
at a community college, or maybe it's a book, or maybe it's a
web page out of Google. It also depends on the background of
the person trying to learn.
I want to reiterate to the OP that object-oriented programming
is *not* a small subject. It involves a change in one's way
of thinking that is not acquired by reading a paragraph.
Furthermore, the new way of thinking is not always useful
in the numerical applications usually targetted by Fortran.
--
pa at panix dot com
| |
| glen herrmannsfeldt 2005-09-23, 7:00 pm |
| Pierre Asselin wrote:
(snip regarding object oriented programming)
> I want to reiterate to the OP that object-oriented programming
> is *not* a small subject. It involves a change in one's way
> of thinking that is not acquired by reading a paragraph.
> Furthermore, the new way of thinking is not always useful
> in the numerical applications usually targetted by Fortran.
It isn't so bad, but it should be done at the higher levels only.
You could take some linear algebra routines and rewrite them
with an object oriented API, but the same code internally.
Assuming that the internal code is debugged, they should work
just fine.
The first object oriented program system that I ever used, though I
didn't know it at the time, was a graphics system called Unified
Graphics. It was designed to be somewhat device independent,
though that might not be related to object orientedness.
It uses an array, called a graphics element, to store information
before it is written to the device. You initialize the element with
one subroutine call, add graphic data (lines, characters, etc.),
with additional calls, and then finally write it to the device,
whichever is currently open, with another call.
The low level routines likely weren't very object oriented.
-- glen
| |
| Gary L. Scott 2005-09-24, 6:58 pm |
| glen herrmannsfeldt wrote:
> Pierre Asselin wrote:
>
> (snip regarding object oriented programming)
>
>
>
> It isn't so bad, but it should be done at the higher levels only.
>
> You could take some linear algebra routines and rewrite them
> with an object oriented API, but the same code internally.
> Assuming that the internal code is debugged, they should work
> just fine.
I believe that API writers, especially for commercial products should
consider supporting both procedural and object programming paradigms
whenever possible. Those that don't like or don't comprehend one or the
other style preferences aren't therefore prevented from getting their
work done. And number one on my recommendation list for procedural APIs
is don't use functions to provide error return or status codes. That
programming style wreaks.
>
> The first object oriented program system that I ever used, though I
> didn't know it at the time, was a graphics system called Unified
> Graphics. It was designed to be somewhat device independent,
> though that might not be related to object orientedness.
>
> It uses an array, called a graphics element, to store information
> before it is written to the device. You initialize the element with
> one subroutine call, add graphic data (lines, characters, etc.),
> with additional calls, and then finally write it to the device,
> whichever is currently open, with another call.
>
> The low level routines likely weren't very object oriented.
>
> -- glen
>
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2005-09-24, 6:58 pm |
| In article <11jb5bjlm0can99@corp.supernews.com>,
"Gary L. Scott" <garyscott@ev1.net> wrote:
> And number one on my recommendation list for procedural APIs
> is don't use functions to provide error return or status codes. That
> programming style wreaks.
I wouldn't have said that had much to do with object orientation or not.
At least in Fortran, it has a lot to do with making the code of
questionable legality. No, I'm not going to argue with Giles about it
(again). But the argument has no correlation with OO.
| |
| Gary L. Scott 2005-09-24, 6:58 pm |
| Richard Maine wrote:
> In article <11jb5bjlm0can99@corp.supernews.com>,
> "Gary L. Scott" <garyscott@ev1.net> wrote:
>
>
>
>
>
> I wouldn't have said that had much to do with object orientation or not.
>
> At least in Fortran, it has a lot to do with making the code of
> questionable legality. No, I'm not going to argue with Giles about it
> (again). But the argument has no correlation with OO.
I don't think I implied that it did. I stated that where possible, a
well designed API should support a procedural programming style as an
alternative to forced OO usage. I then listed one thing that I don't
like about common API design.
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| James Giles 2005-09-24, 6:58 pm |
| Richard Maine wrote:
> In article <11jb5bjlm0can99@corp.supernews.com>,
> "Gary L. Scott" <garyscott@ev1.net> wrote:
>
>
>
> I wouldn't have said that had much to do with object orientation or
> not.
>
> At least in Fortran, it has a lot to do with making the code of
> questionable legality. No, I'm not going to argue with Giles about
> it (again). But the argument has no correlation with OO.
Gee, I didn't even say anything.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
|
| > Up to now, I do not really understand what this OOP means. >
I first learned "structured programming" in Fortran. I think of OOP as
structured programming taken to the next level. Some define OOP by listing
3 characteristics of OOP.
I think of OOP as coding nouns rather than coding verbs.
In OOP data comes first and routines just modify data. OOP involves a close
association of data with the functions that manipulate the data. In Fortran
the data is stored in an instance of a derived type. The subroutines are
associated with the data because the derived type containing it (the data)
is passed to the routine as an argument. The routine cannot be called
without the instance of the derived type.
The code below is "static". Typically OO code involves creating instances
(also called objects) and the methods are either called from the object
C++/VB/C#/Java Object.Method or in the case of Fortran: Method(Object).
David
> To make it simple, suppose I have the following code (below). Can we
> call it OOP programming?
> !----------------------
> program main
> use var
> use calculation
> x=10.
> y=20.
> call addition
> call substraction
> print*,'x=',x
> print*,'y=',y
> print*,'x+y=',w
> print*,'x-y=',z
> end program main
>
> module var
> real :: x,y,w,z
> end module var
>
> module calculation
> use var
> contains
> subroutine addition
> w=x+y
> end subroutine addition
>
> subroutine substraction
> z=x-y
> end subroutine substraction
> end module calculation
>
| |
| Richard Maine 2005-09-26, 3:57 am |
| In article <4eIZe.20203$nq.2065@lakeread05>,
"apm" <Contributor@AdsorptionProcessModeling.com> wrote:
> Typically OO code involves creating instances
> (also called objects) and the methods are either called from the object
> C++/VB/C#/Java Object.Method or in the case of Fortran: Method(Object).
Or, also in the case of Fortran (as of f2003, which adds major
OO-related features), object%method.
| |
|
| >I realized ... I had been using some of the object oriented
> principles for over a decade without knowing that here were terms for
> that style of organization.
How true! I remember reading C++ books and discovering what the organizing
principles I was already using in Fortran were called today.
And, looking back at some very old numerical code OOP appears. The purpose
of Fortran EXTERNAL is to allow "polymorphism". FUNCTIONS and SUBROUTINES
are grouped by and manipulate data in named COMMON blocks.
Now is it true that modern OOP requires fewer arguments be passed to
routines in favor of a greater reliance on COMMON blocks? :->
| |
|
| Through a simple implementation of OOP, we hope we
> will easily see the concept of 1. encapsulation, 2. polymorphism, and
> 3. inheritance. These 3 properties are not IMPOSSIBLE to see even in a
> very simple arithmetic-OOP code. In many C++ books, the authors explain
> OOP concept with simple application.
>
From an OO perspective a scalar is an object. An object may have one or
more properties. The property of a scalar that comes to mind is its numeric
value. The object may also be modified by one or more methods. Two scalars
may be added. For example the following code instantiates two scalar
objects and calls the addition method (indirectly using an operator)
REAL :: a = 1
REAL:: b = 1
PRINT*, a+b
END
Nearly the same code could be used if a and b were vectors. This is because
the addition operator is overloaded to perform scalar addition on scalars
and vector addition on vectors. The PRINT method prints a representation of
a scalar given a scalar argument and a representation of a vector given a
vector argument. This shows encapsulation and polymorphism built into
Fortran 90.
Some argue that OOP is not possible in Fortran 90 because "true" inheritance
is not supported. In my opinion it is possible but does require more work.
To make a Temperature object we "inherit" from the scalar object and include
the Units property.
TYPE Temperature
REAL Value
CHARACTER Units
END TYPE
TYPE(Temperature) T
T%Value = 25
T%Units = "C"
PRINT*, T
Regards,
David
| |
| Pierre Asselin 2005-09-26, 7:00 pm |
| apm <Contributor@adsorptionprocessmodeling.com> wrote:
> And, looking back at some very old numerical code OOP appears. The purpose
> of Fortran EXTERNAL is to allow "polymorphism". FUNCTIONS and SUBROUTINES
> are grouped by and manipulate data in named COMMON blocks.
No smiley ? You can only have one instance of each common block;
that doesn't seem very object-oriented to me. The OO crowd have
a thing called the "singleton pattern", but to make it mandatory ?
> Now is it true that modern OOP requires fewer arguments be passed to
> routines in favor of a greater reliance on COMMON blocks? :->
And *now* you have a smiley ? It's a real effect ! A big class
with too many attributes can be hard to debug because all methods
have access to all the attributes. If an instance of an object
becomes corrupted it is difficult to pinpoint the culprit --just
like what happens in Fortran when too many subroutines interact
through too many common blocks.
In OOP the member variables do look a bit like global variables:
addictively convenient, but dangerous for their unrestricted data
flow. They are different from global variables in that each object
carries its own set of them (i.e. you can have many instances).
--
pa at panix dot com
| |
| Pierre Asselin 2005-09-26, 7:00 pm |
| apm <Contributor@adsorptionprocessmodeling.com> wrote:
> [ ... ]
> Some argue that OOP is not possible in Fortran 90 because "true" inheritance
> is not supported. In my opinion it is possible but does require more work.
> To make a Temperature object we "inherit" from the scalar object and include
> the Units property.
> [ example snipped]
Hmmm yes, you can handle inheritance in languages that don't directly
support object-oriented programming, but that quickly gets out of
hand. If you want an example, dive in the docs of the X windows
system and see what you have to do to subclass an Xt widget. This
in C, but a Fortran 95 version would be about as unwieldy.
--
pa at panix dot com
| |
|
| James Giles wrote:
>
> Richard Maine wrote:
>
> Gee, I didn't even say anything.
It doesn't matter, I hear he's gone berserk and is even talking to ghost
posters... check out "zero compare" thread of some years back - one of
the most idiotic posts you'd ever want to see outside alt.lunatic ngs is
his.
| |
| Gary L. Scott 2005-09-29, 9:57 pm |
| bv wrote:
> James Giles wrote:
>
>
>
> It doesn't matter, I hear he's gone berserk and is even talking to ghost
> posters... check out "zero compare" thread of some years back - one of
> the most idiotic posts you'd ever want to see outside alt.lunatic ngs is
> his.
>
Not very nice...or accurate.
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2005-09-30, 3:57 am |
| In article <11jp6r1ev9b4f2@corp.supernews.com>,
"Gary L. Scott" <garyscott@ev1.net> wrote:
> bv wrote:
>
> Not very nice...or accurate.
That's ok. I'd find the envious attention flattering... if I were
looking for such ego boosts. :-)
| |
| Mr Hrundi V Bakshi 2005-09-30, 3:57 am |
|
"Richard Maine" <nospam@see.signature> wrote in message
news:nospam-FB33D9.20402629092005@news.supernews.com...
> In article <11jp6r1ev9b4f2@corp.supernews.com>,
> "Gary L. Scott" <garyscott@ev1.net> wrote:
>
>
> That's ok. I'd find the envious attention flattering... if I were
> looking for such ego boosts. :-)
Clearly you do, pathetic as it is, but you're obviously used to that.
--
You're Welcome,
Hrundi V.B,
______
"The most successful tyranny is not the one that uses force to assure
uniformity but the one that removes the awareness of other possibilities,
that makes it seem inconceivable that other ways are viable, that removes
the sense that there is an outside." -- Allan Bloom, in The Closing of the
American Mind.
|
|
|
|
|