There was a conference on OOP with the "proceedings" having been published
by Springer. The editors start with something like "One of the benefits of
OOP is better software reusablity...".
Now: How on earth can they know that? To make a proposition like this they
would have to measure software reusability without OOP and with OOP and then
would have to prove that with OOP they get a higher score (a higher number
on their scale) and additionally they would have to prove that the
difference is significant from the point ov view of statistics, as such a
measurment would probably include some sampling.
But is it possible to undertake such an investigation? It simply seems
impossible to me and therefor propositions like the one I started with seem
to have no sense at all.
What do you mean?
Janos Blazi
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
* Janos Blazi wrote:
> Now: How on earth can they know that? To make a proposition like
> this they would have to measure software reusability without OOP and
> with OOP and then would have to prove that with OOP they get a
> higher score (a higher number on their scale) and additionally they
> would have to prove that the difference is significant from the
> point ov view of statistics, as such a measurment would probably
> include some sampling.
They can't know that, of course. Not only would the measurement be
hard in principle as you point out, but very few people who are
actually developing large scale bits of software would be willing to
allow measurements of this kind, *especially* if their large
investment in OOP to gain reuse wasn't paying off!
But they need to be able to make impressive claims or no one would buy
their books.
--tim
In article <··········@goliath.newsfeeds.com>,
Janos Blazi <······@netsurf.de> wrote:
>There was a conference on OOP with the "proceedings" having been published
>by Springer. The editors start with something like "One of the benefits of
>OOP is better software reusablity...".
>
>Now: How on earth can they know that?
It's not something they know, it's something that OOP proponents believe.
Good software reusability has been the holy grail of software engineering
for decades. OOP is believed to provide some enabling technologies for
it. It's been stated as a belief enough times that many people just assume
it's true.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Janos Blazi <······@netsurf.de> wrote in message
···············@goliath.newsfeeds.com...
> There was a conference on OOP with the "proceedings" having been published
> by Springer. The editors start with something like "One of the benefits of
> OOP is better software reusablity...".
>
> Now: How on earth can they know that? To make a proposition like this they
> would have to measure software reusability without OOP and with OOP and
then
> would have to prove that with OOP they get a higher score (a higher number
> on their scale) and additionally they would have to prove that the
> difference is significant from the point ov view of statistics, as such a
> measurment would probably include some sampling.
Gabriel has a lot to say on this topic in his "Patterns of Software" book.
I picked it up mostly for the insight into the whole Lucid thing, but ended
up reading it cover-to-cover. To put his arguments into a nutshell hardly
does them justice, but:
<nutshell>OOP promotes code compression, not code reuse.</nutshell>
Some of his other conclusions are more difficult to reconcile with my
own experience, but this one really resonated.
--
Become a Venture Technologist... <http://www.everest.com/careers/>
If thats what Gabriel said, I disagree, strongly.
On every project I have seen using c++ (which is, in my opinion,
only "marginally" object oriented) the code size, for the functionality,
was far LARGER than it would have been in c or fortran
(which, as far as I know, are not claimed by many folks to be
object ordiented).
I agree that the code in theory "could" have been much smaller.
I believe, however, that c++ makes good programmers lose all
their common sense about simplicity of data structures, and
efficiency).
From Gabriel, interepeted...
<nutshell>OOP promotes code compression, not code reuse.</nutshell>
The test: I tried to use c++ to design a set of classes to support
a "grammar", with "productions", "symbols", "termnal symbols"
as in a normal BNF grammar. I wanted to build an LR(k) parser
gernerator, and LL(k) parser generator, and possibly some
grammar transfromers on this stubstrate.
By the time I finished the c++ .h files, and tought a bit about
such issues as efficiency, and iterating over the productions of
a symbol, or the rhs of a production, and computing the follow
sets, etc. I was not happy.
So, I decided to redo the design the way it would be done in cruffty
old FORTRAN.
To hold the names of the symbols, I used a single "common"
characater array. The productions were done as an array of ints.
If the ints were negative, they "pointed at" the character array".
If they were positive, they "pointed at the int array". Each
production had a length of its right hand side (in symbols), a
pointer to the next production with the same left hand side, a pointer
to the next production with a different left-hand side, the lefhand
side (negative, pointing into the char array), and then the rhs elements
of the production (negative for the termnals, and otherwise pointing at
the "first" production for that symbol.
The above may not be completely accurate, but it gives the general
flavor. I think I also had a "hash table" to map symbol strings to
the first production (if any) that had that production as its lhs symbol,
and the production also had a pointer to the next productin with the
same hash bucket but a different symbol (if any).
I could walk over all productions in the grammar, as each one carried
in its header its length. I could walk over the rhs of any production.
I could walk over the set of productions that had the same lhs. I could
print the productions.
I'm sure I've got one or two details wrong, but this is the point:
the FORTRAN implementation was eaier to dream up, and clearer,
and FAR more efficient, in that rather than doing new to have the
symbols, etc. allocation consisted of merely moving the value of
the number of char slots filled, or the number of int slots filled.
Finally, and this is the point, AFTER the FORTRAN design, it was
evident how to alter the c++ h files to "hide" the FORTRAN
implementation. So WHY, oh WHY, if I could come up with a good
FORTRAN implementation, was I misled down a garden path by
c++ to a poor implemenation, when a AFTER thinking about the
problem in FORTRAN, the c++ implementation could run just as
well as FORTRAN?
Something is really busted in the language design of c++: it somehow
seduces good programmers to write bloated, small, verbose code,
even though they have written better code 2 decades earlier, and
EVEN though the language, in a purely technical sense, is quite
cabable of being very efficient, terse, and able to detect type
misuse at compile time.\
I THINK, but am not sure, that the problem is that there are really two kinds
of objects: large "collections", and small "references" to elements of the
collections. We normally, in FORTRAN, know that
anything that is passed arround is going to be an entire array, or
an integer, float, or complex number. In c++, we forget, and tend to
make objects that are "productions" in a "grammar", and the "production"
obect's state as we know it is "too large to copy" winds
up either as a heap allocated class instance, and we pass references
or pointers to it, or we "encapsulate" and make the "production"
class contain a pointer to the "production body". So then we must
increment and decrement reference counts everytime we return
a production, or assign one. And, generally, somewhere along the
line, alot of code gets written that simply isn't there in the FORTRAN
case.
I have no experience with CLOS, yet. It may not have the c++ problem. But,
clearly, the FORTRAN solution is unlikely to be used with CLOS, as it also is
"class" oriented. Yet, CLOS is also quite capable of supporting the FORTRAN
design, with full "hiding" of the implementation details.
There is another interesting point: the FORTRAN implemntation has a much
"tighter" memory footprint, and is not disturbed by the garbage collector. A
grammar can be quickly written to or read from a file, and the memory working
set of the grammar can be in just 3 or 4 places, and, this can be changed to 2
places: the class instance itself, an adjustable array of fixnums, and a couple
of arrays displaced to it. If the lisp allows, the character array could be
displaced to the fixnum array, Ohterwise, the char codes can be grouped,
converted to fixnums, and strored.The result is a "tight" representation of the
entire grammar, which is all in the same address neighborhood, and can be
written to or read from disk very quickly and easily.
So: OOP CAN be used to make very tight code, that works well, but,
in practice in industry using c++, that is NOT happening (at least where I
work). The classes are far too big, and have far too many data members and
functions, and the data members are themselves
classes, and the fleas have mites. So we have 3+million lines of
c++, with unclean interfaces everywhere. Recompiling the beast
takes so long we only do it, completely, once a week. Even a "normal" full
build, compiling only what "must" be recompiled because the object code depends
on a piece of updated source code, takes 4 to 8 hours, and the executable
sizes (WITHOUT debug information, except for the mangled function names, are
rediculous: over 100Mbytes on some platforms). I think some of the debug
versions are so big that vendor limitations prohibit compiling everything with
full debug information, as the resulting executable size exceeds the system
imposed maximum executable size. The "old" rule of thumb of
about 10 bytes of executable per line of source code seems to
now be about 30 bytes of executable per line of source, at least for
c++.
I completely agree with you as I have had the same experience.
I have been thinking about implementing a BIGNUM package in C++ and I see
that it would be so much easier to implement it in C. I could concentrate on
the mathematical problems instead of dealing with C++. (I must admit I am
not a C++ expert but I am becoming one.)
So what remains is this:
In C I would have to write add(x,y,z) instead of writing z=x+y, but I am
asking myself, whether the additional elegance is worth the troubles and the
*loss of efficiency*. (I wrote about this in another posting concerning copy
constructors.)
And even KNUTH said that he did not understand OOP at the moment. So what?
Janos B.
ArolAmbler <··········@aol.com> schrieb in im Newsbeitrag:
·····························@nso-fa.aol.com...
> If thats what Gabriel said, I disagree, strongly.
>
> On every project I have seen using c++ (which is, in my opinion,
> only "marginally" object oriented) the code size, for the functionality,
> was far LARGER than it would have been in c or fortran
>
> (which, as far as I know, are not claimed by many folks to be
> object ordiented).
> I agree that the code in theory "could" have been much smaller.
> I believe, however, that c++ makes good programmers lose all
> their common sense about simplicity of data structures, and
> efficiency).
>
> From Gabriel, interepeted...
> <nutshell>OOP promotes code compression, not code reuse.</nutshell>
>
>
>
> The test: I tried to use c++ to design a set of classes to support
> a "grammar", with "productions", "symbols", "termnal symbols"
> as in a normal BNF grammar. I wanted to build an LR(k) parser
> gernerator, and LL(k) parser generator, and possibly some
> grammar transfromers on this stubstrate.
>
> By the time I finished the c++ .h files, and tought a bit about
> such issues as efficiency, and iterating over the productions of
> a symbol, or the rhs of a production, and computing the follow
> sets, etc. I was not happy.
>
>
> So, I decided to redo the design the way it would be done in cruffty
> old FORTRAN.
> To hold the names of the symbols, I used a single "common"
> characater array. The productions were done as an array of ints.
> If the ints were negative, they "pointed at" the character array".
> If they were positive, they "pointed at the int array". Each
> production had a length of its right hand side (in symbols), a
> pointer to the next production with the same left hand side, a pointer
> to the next production with a different left-hand side, the lefhand
> side (negative, pointing into the char array), and then the rhs elements
> of the production (negative for the termnals, and otherwise pointing at
> the "first" production for that symbol.
>
> The above may not be completely accurate, but it gives the general
> flavor. I think I also had a "hash table" to map symbol strings to
> the first production (if any) that had that production as its lhs symbol,
> and the production also had a pointer to the next productin with the
> same hash bucket but a different symbol (if any).
>
> I could walk over all productions in the grammar, as each one carried
> in its header its length. I could walk over the rhs of any production.
> I could walk over the set of productions that had the same lhs. I could
> print the productions.
>
> I'm sure I've got one or two details wrong, but this is the point:
> the FORTRAN implementation was eaier to dream up, and clearer,
> and FAR more efficient, in that rather than doing new to have the
> symbols, etc. allocation consisted of merely moving the value of
> the number of char slots filled, or the number of int slots filled.
>
> Finally, and this is the point, AFTER the FORTRAN design, it was
> evident how to alter the c++ h files to "hide" the FORTRAN
> implementation. So WHY, oh WHY, if I could come up with a good
> FORTRAN implementation, was I misled down a garden path by
> c++ to a poor implemenation, when a AFTER thinking about the
> problem in FORTRAN, the c++ implementation could run just as
> well as FORTRAN?
>
> Something is really busted in the language design of c++: it somehow
> seduces good programmers to write bloated, small, verbose code,
> even though they have written better code 2 decades earlier, and
> EVEN though the language, in a purely technical sense, is quite
> cabable of being very efficient, terse, and able to detect type
> misuse at compile time.\
>
> I THINK, but am not sure, that the problem is that there are really two
kinds
> of objects: large "collections", and small "references" to elements of the
> collections. We normally, in FORTRAN, know that
> anything that is passed arround is going to be an entire array, or
> an integer, float, or complex number. In c++, we forget, and tend to
> make objects that are "productions" in a "grammar", and the "production"
> obect's state as we know it is "too large to copy" winds
> up either as a heap allocated class instance, and we pass references
> or pointers to it, or we "encapsulate" and make the "production"
> class contain a pointer to the "production body". So then we must
> increment and decrement reference counts everytime we return
> a production, or assign one. And, generally, somewhere along the
> line, alot of code gets written that simply isn't there in the FORTRAN
> case.
>
> I have no experience with CLOS, yet. It may not have the c++ problem.
But,
> clearly, the FORTRAN solution is unlikely to be used with CLOS, as it also
is
> "class" oriented. Yet, CLOS is also quite capable of supporting the
FORTRAN
> design, with full "hiding" of the implementation details.
>
> There is another interesting point: the FORTRAN implemntation has a much
> "tighter" memory footprint, and is not disturbed by the garbage collector.
A
> grammar can be quickly written to or read from a file, and the memory
working
> set of the grammar can be in just 3 or 4 places, and, this can be changed
to 2
> places: the class instance itself, an adjustable array of fixnums, and a
couple
> of arrays displaced to it. If the lisp allows, the character array could
be
> displaced to the fixnum array, Ohterwise, the char codes can be grouped,
> converted to fixnums, and strored.The result is a "tight" representation
of the
> entire grammar, which is all in the same address neighborhood, and can be
> written to or read from disk very quickly and easily.
>
> So: OOP CAN be used to make very tight code, that works well, but,
> in practice in industry using c++, that is NOT happening (at least where I
> work). The classes are far too big, and have far too many data members
and
> functions, and the data members are themselves
> classes, and the fleas have mites. So we have 3+million lines of
> c++, with unclean interfaces everywhere. Recompiling the beast
> takes so long we only do it, completely, once a week. Even a "normal"
full
> build, compiling only what "must" be recompiled because the object code
depends
> on a piece of updated source code, takes 4 to 8 hours, and the executable
> sizes (WITHOUT debug information, except for the mangled function names,
are
> rediculous: over 100Mbytes on some platforms). I think some of the debug
> versions are so big that vendor limitations prohibit compiling everything
with
> full debug information, as the resulting executable size exceeds the
system
> imposed maximum executable size. The "old" rule of thumb of
> about 10 bytes of executable per line of source code seems to
> now be about 30 bytes of executable per line of source, at least for
> c++.
>
>
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
In article <··········@goliath.newsfeeds.com>,
Janos Blazi <······@netsurf.de> wrote:
>In C I would have to write add(x,y,z) instead of writing z=x+y, but I am
>asking myself, whether the additional elegance is worth the troubles and the
>*loss of efficiency*. (I wrote about this in another posting concerning copy
>constructors.)
The difference between add(x,y,z) and z=x+y has nothing to do with OOP.
The latter notation is enabled by operator overloading, not OOP.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <·····························@nso-fa.aol.com>,
··········@aol.com (ArolAmbler) wrote:
> The test: I tried to use c++ to design a set of classes to support
> a "grammar", with "productions", "symbols", "termnal symbols"
> as in a normal BNF grammar. I wanted to build an LR(k) parser
> gernerator, and LL(k) parser generator, and possibly some
> grammar transfromers on this stubstrate.
If you're interested in an elegant OO implementation of a parser
generator, have a look at SableCC.
http://www.sable.mcgill.ca/
Incidentally, the abstract of their paper at
http://computer.org/proceedings/tools/8482/84820140abs.htm
includes the text:
> We conclude that the use of object-oriented techniques significantly
> reduces the length of the programmer written code, can shorten the
> development time and finally, makes the code easier to read and
> maintain.
I was impressed with the code, but of course it's not conclusive proof
that OOP is better or worse than anything else.
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
ArolAmbler <··········@aol.com> wrote in message
··································@nso-fa.aol.com...
> If thats what Gabriel said, I disagree, strongly.
>
> On every project I have seen using c++ (which is, in my opinion,
> only "marginally" object oriented) the code size, for the functionality,
> was far LARGER than it would have been in c or fortran
>
> (which, as far as I know, are not claimed by many folks to be
> object ordiented).
> I agree that the code in theory "could" have been much smaller.
> I believe, however, that c++ makes good programmers lose all
> their common sense about simplicity of data structures, and
> efficiency).
>
> From Gabriel, interepeted...
> <nutshell>OOP promotes code compression, not code reuse.</nutshell>
Again, I have to recommend reading Gabriel rather than drawing any
significant conclusions from my paraphrasing of *one* of his points.
The larger context of this idea was along the lines that, software
development is hard, and OOP did not make it easier -- it just
provided a different perspective and some different trade-offs.
My own experience is that OO designs *can* offer code compression --
not that the necessarily *will* by default. The insight I attribute
to Gabriel is that, before his book, I did not think of the nominal
productivity increase I got from OOP as "compression". I could see
that there was some benefit to me, and to my peers who had worked
closely with me in specifying the class hierarchy we were working on,
but was then dissappointed to see that it did not appear to translate
outside of that group.
> [...]
> So: OOP CAN be used to make very tight code, that works well, but,
> in practice in industry using c++, that is NOT happening (at least where I
> work). The classes are far too big, and have far too many data members
and
> functions, and the data members are themselves
> classes, and the fleas have mites. So we have 3+million lines of
> c++, with unclean interfaces everywhere. Recompiling the beast
> takes so long we only do it, completely, once a week. Even a "normal"
full
> build, compiling only what "must" be recompiled because the object code
depends
> on a piece of updated source code, takes 4 to 8 hours, and the executable
> sizes (WITHOUT debug information, except for the mangled function names,
are
> rediculous: over 100Mbytes on some platforms). I think some of the debug
> versions are so big that vendor limitations prohibit compiling everything
with
> full debug information, as the resulting executable size exceeds the
system
> imposed maximum executable size. The "old" rule of thumb of
> about 10 bytes of executable per line of source code seems to
> now be about 30 bytes of executable per line of source, at least for
> c++.
This is a lot to lay at the feet of C++. Nothing in the C++ language
inherantly (sic) precludes you from mixing good, old-fashioned functional
decomposition with your objects as appropriate. Common Lisp is even
better at supporting a mix of styles -- but you can do it with C++. But
the majority of C++ programmers seem not to want to work that way. Thus
in Java we see "useless" constructs like stand-alone functions atrophied
away, replaced by the end-all-be-all class abstraction.
The C++ crowd may be subtley encouraged down this path by the (IMO)
gratuitous syntactic distinctions between "member" and "non-member"
functions. I personally find the generic function style of polymorphic
dispatch abstraction much more palatable for exactly this reason.
-- Kaelin
--
Become a Venture Technologist... <http://www.everest.com/careers/>
As far as I can tell, there is no evidence that OO has actually
increased reuse. And I did go looking. VB components may be an
exception.
You still have the same problems with reuse (it's more fun to
rewrite than to bleed over someone else's code; they didn't
document their objects well enough; they had different
reliability/performance/functional requirements and I need a
little more of one of them etc). Whether to blame C++ for that is
debateable.
OO is what I call 'noun' based programming. Before that everyone
used 'verb' based programming, AKA procedural programming. Surely
some problems fit one approach better, other problems fit another
better. So writing GUIs seems to be a great candidate for OO
because all the things on the are well done as objects. But doing
a frequency spectrum of an audio file seems to fit procedural
programming best. Bigots will get it wrong a lot of the time.
C++ also encourages another bad thing that was mentioned in one
of the other threads. It encourages you to over-structure your
software and put all the information about the problem domain
into the class structure. I say this as an observation; having
never used C++ seriously I don't know why this happens. This
means that when the problem domain changes you are in for a major
rewrite. This is part of the reason 'soft'ware is harder to
change than 'hard'ware.
(I am just now learning Lisp after 25 years as a programmer,
mainly doing assembler. I am interesting in doing the higher
level analysis of the music files I referred to above in Lisp.
Any thoughts on this would also be welcome.)
Tim Josling
Janos Blazi wrote:
>
> There was a conference on OOP with the "proceedings" having been published
> by Springer. The editors start with something like "One of the benefits of
> OOP is better software reusablity...".
>
> Now: How on earth can they know that? To make a proposition like this they
> would have to measure software reusability without OOP and with OOP and then
> would have to prove that with OOP they get a higher score (a higher number
> on their scale) and additionally they would have to prove that the
> difference is significant from the point ov view of statistics, as such a
> measurment would probably include some sampling.
>
> But is it possible to undertake such an investigation? It simply seems
> impossible to me and therefor propositions like the one I started with seem
> to have no sense at all.
>
> What do you mean?
>
> Janos Blazi
>
> -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
> http://www.newsfeeds.com The Largest Usenet Servers in the World!
> ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
What I do not understand is this: OO code may be partly reusable or not. But
which (even theretical) advantage does it offer versus a traditional library
that may use structures instead os "objects".
Janos Blazi
Tim Josling <···@melbpc.org.au> schrieb in im Newsbeitrag:
················@melbpc.org.au...
> As far as I can tell, there is no evidence that OO has actually
> increased reuse. And I did go looking. VB components may be an
> exception.
>
> You still have the same problems with reuse (it's more fun to
> rewrite than to bleed over someone else's code; they didn't
> document their objects well enough; they had different
> reliability/performance/functional requirements and I need a
> little more of one of them etc). Whether to blame C++ for that is
> debateable.
>
> OO is what I call 'noun' based programming. Before that everyone
> used 'verb' based programming, AKA procedural programming. Surely
> some problems fit one approach better, other problems fit another
> better. So writing GUIs seems to be a great candidate for OO
> because all the things on the are well done as objects. But doing
> a frequency spectrum of an audio file seems to fit procedural
> programming best. Bigots will get it wrong a lot of the time.
>
> C++ also encourages another bad thing that was mentioned in one
> of the other threads. It encourages you to over-structure your
> software and put all the information about the problem domain
> into the class structure. I say this as an observation; having
> never used C++ seriously I don't know why this happens. This
> means that when the problem domain changes you are in for a major
> rewrite. This is part of the reason 'soft'ware is harder to
> change than 'hard'ware.
>
> (I am just now learning Lisp after 25 years as a programmer,
> mainly doing assembler. I am interesting in doing the higher
> level analysis of the music files I referred to above in Lisp.
> Any thoughts on this would also be welcome.)
>
> Tim Josling
>
> Janos Blazi wrote:
> >
> > There was a conference on OOP with the "proceedings" having been
published
> > by Springer. The editors start with something like "One of the benefits
of
> > OOP is better software reusablity...".
> >
> > Now: How on earth can they know that? To make a proposition like this
they
> > would have to measure software reusability without OOP and with OOP and
then
> > would have to prove that with OOP they get a higher score (a higher
number
> > on their scale) and additionally they would have to prove that the
> > difference is significant from the point ov view of statistics, as such
a
> > measurment would probably include some sampling.
> >
> > But is it possible to undertake such an investigation? It simply seems
> > impossible to me and therefor propositions like the one I started with
seem
> > to have no sense at all.
> >
> > What do you mean?
> >
> > Janos Blazi
> >
> > -----------== Posted via Newsfeeds.Com, Uncensored Usenet News
==----------
> > http://www.newsfeeds.com The Largest Usenet Servers in the
World!
> > ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers
==-----
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
From: Robert Monfera
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <38813FC1.65E9F2BA@fisec.com>
Janos Blazi wrote:
>
> What I do not understand is this: OO code may be partly reusable or
> not. But which (even theretical) advantage does it offer versus a
> traditional library that may use structures instead os "objects".
Polymorphism and inheritance may give you advantages in terms of
development time and abstraction (compactness, clarity), especially when
working on complex problems. I said 'may' because, as with so many
things, you need to be open for it to appreciate it. Recently several
posters have questioned the benefits of OO as if to get approval of
their (mis)understandings - with this attitude, they are unlikely
recipients of any benefit. Your question also does not reflect a desire
to actually understand anything, as in this case you could just pick up
an introductory book to start with.
Regards
Robert
I know one (i.e. 1) problem where OO is ideal: programming the Win32
interface using MFC. Here object arise in a natural way. (And of course the
Win32 interface is simple enough and you can program it directly without
having to use some toolkit. Probably nobody will program X-Windows
directly.)
Well, this is not much.
J.B.
Robert Monfera <·······@fisec.com> schrieb in im Newsbeitrag:
·················@fisec.com...
>
> Janos Blazi wrote:
> >
> > What I do not understand is this: OO code may be partly reusable or
> > not. But which (even theretical) advantage does it offer versus a
> > traditional library that may use structures instead os "objects".
>
> Polymorphism and inheritance may give you advantages in terms of
> development time and abstraction (compactness, clarity), especially when
> working on complex problems. I said 'may' because, as with so many
> things, you need to be open for it to appreciate it. Recently several
> posters have questioned the benefits of OO as if to get approval of
> their (mis)understandings - with this attitude, they are unlikely
> recipients of any benefit. Your question also does not reflect a desire
> to actually understand anything, as in this case you could just pick up
> an introductory book to start with.
>
> Regards
> Robert
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
Janos Blazi <······@netsurf.de> wrote:
> I know one (i.e. 1) problem where OO is ideal: programming the Win32
> interface using MFC.
For more suggestion you owe it to yourself to consult
<news:comp.object>.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: Robert Monfera
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <3883D704.BC45F0E9@fisec.com>
Janos Blazi wrote:
>
> I know one (i.e. 1) problem where OO is ideal: programming the Win32
> interface using MFC.
[...]
> Well, this is not much.
True, but at least you don't pretend you know it all. Openness to learn
is always positive news.
It is a common thinking that GUI and/or MFC programming is the main
beneficiary of OO. I can only guess what the reason is: GUIs are highly
visible instances of OO, and it is well known that Swing, Gnome and MFC
are based on OO. Many programmers and quasi-programmers meet OO through
their first encounter with MFC.
OO being used in MFC is just a consequence of the fact that it is a good
idea overall, and some people invented OO and GUI before (i.e., people
at Xerox PARC inventing GUI, OO and creating Smalltalk and its
forerunners), so MS was able to 'obtain' it from somewhere.
Payroll calculation or circuit design receives just as much or more
benefits from OO as application 'foundations'. OO really shines when
the goal is to provide a reflection on objects (entities) and their
behavior when they are in a complex web of relationships. (Most GUIs
aren't very complex).
I'd like to give an example for OO, where it is very useful and it is
nothing to do with MFC. Of course, the example is simplified.
Let's take banking. Banks have huge portfolios of loans, deposits and
other instruments. Also, these main product groups are further divided,
e.g., there are time deposits and checking accounts within deposits.
All loans and deposits have a nominal (face) value, and all of them have
an origination date. Only time deposits and fixed term loans mature on
a certain date, though. Most loans are typically amongst assets in the
balance sheet and carry default risks. Transactions in foreign
currencies are subject to exchange rate risk. All loans and deposits
appear on the balance sheet, while financial derivatives are often not.
The interest on many loans and deposits is bound to market rates (known
as variable rate instruments).
At this point we see that there are numerous classifying aspects and
numerous dividing lines that determine the behavior, profitability, risk
and legal meanings of portfolios.
What OO allows is the ability to leverage similarities within the groups
determined by the dividing lines. Everything is determined at its
proper level. If all instruments have an origination date, you may
create a slot for class Instrument. If all term instruments (be it
loans or deposits) have maturity dates, you can create this slot for
class Term-instrument. If interest rate risks for all fixed rate
instruments are determined in principally the same way, you may create a
generic function for that class, and specialize (modify or overrule) for
exceptions and specializations. For a loan issued in a foreign
currency, you may calculate the total risk as a (method) combination of
exchange rate risk and default risk.
If one is aiming at implementing a profitability and risk analysis
system without considering OO concepts and techniques, he will find that
there are thousands of combinations of features and behaviors, and he
will be doomed to design and implement all these manually. By the time
he is 20% done, some requirements change such a way that it may be
impossible for him to ever catch up with the project schedule. He may
also implement a poor man's OO on his own without him knowing.
With polymorphism and inheritance, it is more convenient to separate and
define orthogonal behaviors.
Thanks to people who invested much thought and resources in it, the most
complete OO environment is also available as part of Common Lisp: CLOS.
The fact that not everyone in the Lisp community is enthusiastic about
OO programming is not a disapproval of OO - few CL features enjoy
undivided appreciation. One reason is that CL supported or enabled OO
features already even before having CLOS or inventing the term 'object
orientation'.
If you are skeptical about OO, try to challenge yourself and think
through familiar problem domains to see how OO concepts could possibly
be used. Don't start with MFC - start with familiar problems that are
complex and real.
Regards
Robert
Your recent responses to my questions consist of three parts:
(i) pretty informative and interesting
(ii) breathtakingly naive (as though I had not been struggling with OO for
years; as though I had not read about it;)
(iii) plainly offensive.
And it is difficult to part the wheat and the chaff. I think I am not going
to.
J.B.
Robert Monfera <·······@fisec.com> schrieb in im Newsbeitrag:
·················@fisec.com...
>
> Janos Blazi wrote:
> >
> > I know one (i.e. 1) problem where OO is ideal: programming the Win32
> > interface using MFC.
> [...]
> > Well, this is not much.
>
> True, but at least you don't pretend you know it all. Openness to learn
> is always positive news.
>
> It is a common thinking that GUI and/or MFC programming is the main
> beneficiary of OO. I can only guess what the reason is: GUIs are highly
> visible instances of OO, and it is well known that Swing, Gnome and MFC
> are based on OO. Many programmers and quasi-programmers meet OO through
> their first encounter with MFC.
>
> OO being used in MFC is just a consequence of the fact that it is a good
> idea overall, and some people invented OO and GUI before (i.e., people
> at Xerox PARC inventing GUI, OO and creating Smalltalk and its
> forerunners), so MS was able to 'obtain' it from somewhere.
>
> Payroll calculation or circuit design receives just as much or more
> benefits from OO as application 'foundations'. OO really shines when
> the goal is to provide a reflection on objects (entities) and their
> behavior when they are in a complex web of relationships. (Most GUIs
> aren't very complex).
>
> I'd like to give an example for OO, where it is very useful and it is
> nothing to do with MFC. Of course, the example is simplified.
>
> Let's take banking. Banks have huge portfolios of loans, deposits and
> other instruments. Also, these main product groups are further divided,
> e.g., there are time deposits and checking accounts within deposits.
>
> All loans and deposits have a nominal (face) value, and all of them have
> an origination date. Only time deposits and fixed term loans mature on
> a certain date, though. Most loans are typically amongst assets in the
> balance sheet and carry default risks. Transactions in foreign
> currencies are subject to exchange rate risk. All loans and deposits
> appear on the balance sheet, while financial derivatives are often not.
> The interest on many loans and deposits is bound to market rates (known
> as variable rate instruments).
>
> At this point we see that there are numerous classifying aspects and
> numerous dividing lines that determine the behavior, profitability, risk
> and legal meanings of portfolios.
>
> What OO allows is the ability to leverage similarities within the groups
> determined by the dividing lines. Everything is determined at its
> proper level. If all instruments have an origination date, you may
> create a slot for class Instrument. If all term instruments (be it
> loans or deposits) have maturity dates, you can create this slot for
> class Term-instrument. If interest rate risks for all fixed rate
> instruments are determined in principally the same way, you may create a
> generic function for that class, and specialize (modify or overrule) for
> exceptions and specializations. For a loan issued in a foreign
> currency, you may calculate the total risk as a (method) combination of
> exchange rate risk and default risk.
>
> If one is aiming at implementing a profitability and risk analysis
> system without considering OO concepts and techniques, he will find that
> there are thousands of combinations of features and behaviors, and he
> will be doomed to design and implement all these manually. By the time
> he is 20% done, some requirements change such a way that it may be
> impossible for him to ever catch up with the project schedule. He may
> also implement a poor man's OO on his own without him knowing.
>
> With polymorphism and inheritance, it is more convenient to separate and
> define orthogonal behaviors.
>
> Thanks to people who invested much thought and resources in it, the most
> complete OO environment is also available as part of Common Lisp: CLOS.
> The fact that not everyone in the Lisp community is enthusiastic about
> OO programming is not a disapproval of OO - few CL features enjoy
> undivided appreciation. One reason is that CL supported or enabled OO
> features already even before having CLOS or inventing the term 'object
> orientation'.
>
> If you are skeptical about OO, try to challenge yourself and think
> through familiar problem domains to see how OO concepts could possibly
> be used. Don't start with MFC - start with familiar problems that are
> complex and real.
>
> Regards
> Robert
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
Janos Blazi wrote:
>
> Your recent responses to my questions consist of three parts:
> (i) pretty informative and interesting
> (ii) breathtakingly naive (as though I had not been struggling with OO for
> years; as though I had not read about it;)
> (iii) plainly offensive.
>
> And it is difficult to part the wheat and the chaff. I think I am not going
> to.
>
> J.B.
>
Well, I don't really see how you can complain about the responses you
get when you start a thread called "Entirely off-topic"...
I have not complained about "responses" as all other responses were very
interesting and nice.
J.B.
Joseph Dale <·····@uclink4.berkeley.edu> schrieb in im Newsbeitrag:
·················@uclink4.berkeley.edu...
> Janos Blazi wrote:
> >
> > Your recent responses to my questions consist of three parts:
> > (i) pretty informative and interesting
> > (ii) breathtakingly naive (as though I had not been struggling with OO
for
> > years; as though I had not read about it;)
> > (iii) plainly offensive.
> >
> > And it is difficult to part the wheat and the chaff. I think I am not
going
> > to.
> >
> > J.B.
> >
>
> Well, I don't really see how you can complain about the responses you
> get when you start a thread called "Entirely off-topic"...
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
From: Scott Ribe
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <3884A193.2EE3628@miqs.com>
Janos Blazi wrote:
>
> Your recent responses to my questions consist of three parts:
> (i) pretty informative and interesting
I thought so too.
> (ii) breathtakingly naive (as though I had not been struggling with OO for
> years; as though I had not read about it;)
Struggling for years? Obviously, you're missing something.
> (iii) plainly offensive.
Why? Because he points out that you must have missed something?
> And it is difficult to part the wheat and the chaff. I think I am not going
> to.
Maybe this is why you'll never get it.
Janos Blazi <······@netsurf.de> wrote:
> Your recent responses to my questions consist of three parts:
> (ii) breathtakingly naive (as though I had not been struggling with OO for
> years; as though I had not read about it;)
Earlier you wrote:
> What I do not understand is this: OO code may be partly reusable or not. But
> which (even theretical) advantage does it offer versus a traditional library
> that may use structures instead os "objects".
I simply don't understand how you get these two statements together.
If you have been investigating OO for years there shouldn't have been
anything in this thread you didn't already know. And why do you call it
"struggling" as if OO were particularly complicated compared to other
approaches? From what I understand, and I may well recall this wrongly,
you're teaching computer science courses at a german university. If this
is the case I can't believe at all that you don't have a good grasp of
OO concepts.
So, this leaves me wondering what you're up to. Your response to Robert
Monfera smells of a hidden agenda that I cannot fathom. Again, I may
well be wrong, but I just don't see the point in your original question.
Even more so, I don't understand why you're asking in comp.lang.lisp
instead of in, say, comp.object[.moderated] or comp.software-eng.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: Erik Naggum
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <3157299588639428@naggum.no>
* Janos Blazi -> Robert Monfera
| Your recent responses to my questions consist of three parts:
| (i) pretty informative and interesting
| (ii) breathtakingly naive (as though I had not been struggling with OO for
| years; as though I had not read about it;)
| (iii) plainly offensive.
|
| And it is difficult to part the wheat and the chaff. I think I am not
| going to.
being able to handle information productively when it runs counter to
one's existing beliefs is perhaps the defining attribute of an operative
intelligence, since it defines how we deal with information from which we
can either learn or recoil, if we don't ignore it as "not grasped".
there is ample evidence that you lack this defining attribute and there
are few redeeming qualities to your many _really_ stupid postings in this
newsgroup. had you actually been interested in the topic at hand, you
would also have been willing to learn whatever was learnable here -- yet
this is where you fail miserable, evidently on _purpose_.
I wonder why people even bother to reply to you with anything technically
useful that you are clearly _unwilling_ to grasp unless you already agree
with it, in which case you insult people for being naive.
please, go annoy people someplace else with your breathtaking stupidity.
#:Erik
"Janos Blazi" <······@netsurf.de> writes:
> I know one (i.e. 1) problem where OO is ideal: programming the Win32
> interface using MFC. Here object arise in a natural way. (And of course the
> Win32 interface is simple enough and you can program it directly without
> having to use some toolkit. Probably nobody will program X-Windows
> directly.)
MFC *sucks*. In some places it's just a single-molecule thin
layer around WIN32 (which also, incidentally, sucks). In other places
it offers classes with similar (but inferior) functionality to
standard C++ classes, e.g, strings, collections etc. It also uses,
throughout, some variant of Hungarian naming, which I find ugly and
useless in the extreme.
I've just spent some time playing with CAPI (in Harlequin's
LispWorks), and this has made me even more unhappy about having to use
Visual Studio, Visual C++ and MFC in my job.
//Raymond.
From: dave linenberg
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <38867FE0.65FB63FF@home.com>
Seems like we are getting into a C++ discussion here as well.....
Qt (www.troll.no) is a much better class library, for those who still want to
stay in the C++ world (free for linux, unix), and have had a miserable time
GUI programming with MFC. (I agree, - MFC is pretty much the best example of
the most horribly designed code I've ever seen. MFC includes the source, so you
can really see how bad the thing is written).
Getting back to Lisp, I would by all means take a look at Lisp/CLOS to see how
wonderfully fun and exciting programming can become, if you don't have the
requirements of writing your program in C++. Goodbye templates. Goodbye typing.
Goodbye garbage collection. Goodbye ugly pointer syntax. Hello productivity.
Dave Linenberg
Raymond Wiker wrote:
> "Janos Blazi" <······@netsurf.de> writes:
>
> > I know one (i.e. 1) problem where OO is ideal: programming the Win32
> > interface using MFC. Here object arise in a natural way. (And of course the
> > Win32 interface is simple enough and you can program it directly without
> > having to use some toolkit. Probably nobody will program X-Windows
> > directly.)
>
> MFC *sucks*. In some places it's just a single-molecule thin
> layer around WIN32 (which also, incidentally, sucks). In other places
> it offers classes with similar (but inferior) functionality to
> standard C++ classes, e.g, strings, collections etc. It also uses,
> throughout, some variant of Hungarian naming, which I find ugly and
> useless in the extreme.
>
> I've just spent some time playing with CAPI (in Harlequin's
> LispWorks), and this has made me even more unhappy about having to use
> Visual Studio, Visual C++ and MFC in my job.
>
> //Raymond.
In my original posting I simply asked if it was well proven that OOP results
in higher code reusability. I suspected that 'higher code reusability' is
hardly well defined at all and even if we could find some good definition
for i,t it would be almost impossible to check this claim by experiment.
There are simply no experimental data. And if this is true then it is
scientifically dishonest to make such propositions in scientific journals.
(And I spoke about publications published by Springer, the best scientific
publisher in my opinion.) The reason for my posting was that I was shocked
that this nonsense is knocking on heavens door i.e. it appears in Springer
catalogues.
I then received some interesting answers and that was that. Now to your
response:
(1)
Of course OOP can be fun. Why not. I cannot give any judgement on CLOS, I
understand it not enough or I have not really dealt with it, I have never
written any applications using CLOS. But it may be very nice, I take your
word for it and I have no reason for not believing you.
(2)
As to the quality of MFC: Again I cannot judge the quality of the code as I
have never looked at the implemenation. But I have written one or two
applications that *use* MFC and it works, the code is fast enough, I get the
feeling I was used to when I used DOS.
Pease tell me, why MFC is badly (or even 'horribly") implemented. Which
parts are badly implemented, in which files are these parts and why is the
implementation bad. If you tell me, I can check it myself. Otherwise it is
difficult as MFC consists of many, many lines of code.
(3)
I have not said anything against the LISP syntax but I do not know the
meaning of the word 'ugly pointer syntax' either. A C++ user may find that
writing
(nth i x)
is not less ugly than
x[i].
But this is a matter of taste of course.
(4)
To sum up: Your response is ok. You probably did not read my original
message and judged it from the last responses, which is *very* misleading
but it is ok.
(5)
And finally: After having received some interesting and nice responses I
also have received responses from maniacs. Well, this is not too bad, I
simply do not read them. This is the price I have to pay for getting the
other, nice responses.
(Alas, matters were a bit different this time as I started getting indecent
responses from somebody I liked.)
J.B.
dave linenberg <········@home.com> schrieb in im Newsbeitrag:
·················@home.com...
> Seems like we are getting into a C++ discussion here as well.....
> Qt (www.troll.no) is a much better class library, for those who still
want to
> stay in the C++ world (free for linux, unix), and have had a miserable
time
> GUI programming with MFC. (I agree, - MFC is pretty much the best
example of
> the most horribly designed code I've ever seen. MFC includes the source,
so you
> can really see how bad the thing is written).
>
> Getting back to Lisp, I would by all means take a look at Lisp/CLOS to see
how
> wonderfully fun and exciting programming can become, if you don't have the
> requirements of writing your program in C++. Goodbye templates. Goodbye
typing.
> Goodbye garbage collection. Goodbye ugly pointer syntax. Hello
productivity.
>
> Dave Linenberg
>
>
> Raymond Wiker wrote:
>
> > "Janos Blazi" <······@netsurf.de> writes:
> >
> > > I know one (i.e. 1) problem where OO is ideal: programming the Win32
> > > interface using MFC. Here object arise in a natural way. (And of
course the
> > > Win32 interface is simple enough and you can program it directly
without
> > > having to use some toolkit. Probably nobody will program X-Windows
> > > directly.)
> >
> > MFC *sucks*. In some places it's just a single-molecule thin
> > layer around WIN32 (which also, incidentally, sucks). In other places
> > it offers classes with similar (but inferior) functionality to
> > standard C++ classes, e.g, strings, collections etc. It also uses,
> > throughout, some variant of Hungarian naming, which I find ugly and
> > useless in the extreme.
> >
> > I've just spent some time playing with CAPI (in Harlequin's
> > LispWorks), and this has made me even more unhappy about having to use
> > Visual Studio, Visual C++ and MFC in my job.
> >
> > file://Raymond.
>
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
In article <··········@goliath.newsfeeds.com>,
Janos Blazi <······@netsurf.de> wrote:
>What I do not understand is this: OO code may be partly reusable or not. But
>which (even theretical) advantage does it offer versus a traditional library
>that may use structures instead os "objects".
I believe the advantages were expected to come from subclassing and
inheritance. If you're implementing something that's "almost like X",
rather than copying X's code and modifying it, you make a subclass of X.
This way, if changes are made to X's implementation (e.g. performance
improvements, bug fixes), your subclass automatically reaps the benefits
immediately -- you don't have to copy the new implementation and merge your
changes into it again.
OO is also expected to encourage better abstraction, because you package
code together with data, and many OO languages enforce encapsulation.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
>
> In article <··········@goliath.newsfeeds.com>,
> Janos Blazi <······@netsurf.de> wrote:
> >What I do not understand is this: OO code may be partly reusable or not. But
> >which (even theretical) advantage does it offer versus a traditional library
> >that may use structures instead os "objects".
>
> I believe the advantages were expected to come from subclassing and
> inheritance. If you're implementing something that's "almost like X",
> rather than copying X's code and modifying it, you make a subclass of X.
> This way, if changes are made to X's implementation (e.g. performance
> improvements, bug fixes), your subclass automatically reaps the benefits
> immediately -- you don't have to copy the new implementation and merge your
> changes into it again.
But most OO systems has rules prohibiting changes unless the
superclass explicit allows it. Normally the only thing that can be
redifined are functions that are declared to be virtual/generic.
That means classes can only be used in the ways that the author has
expected in advance.
Library functions can often be changed a little by making a wrapper
function.
Oluf
From: Friedrich Dominicus
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <3883129F.FDC8FC2F@inka.de>
Asle Olufsen wrote:
>
> Barry Margolin <······@bbnplanet.com> writes:
>
> But most OO systems has rules prohibiting changes unless the
> superclass explicit allows it.
>Normally the only thing that can be
> redifined are functions that are declared to be virtual/generic.
This is not true in general. C++ is a candidate for that. In Eiffel and
Sather you explicitly have to state if a methods is not allowed to be
changed. There are some features for which this makes sense. E.g Object
copying and the like.
> That means classes can only be used in the ways that the author has
> expected in advance.
Now this would be a point to critizise in language which default to
non-redefining features.
>
> Library functions can often be changed a little by making a wrapper
> function.
Really great of course one can write wrappers, but that has nothing to
do with usefulness of object-oriented approaches to programming.
I would say OO-offers some benefits but it's not a silver bullet.
Regards
Friedrich
In article <··············@opus.nextel.no>,
Asle Olufsen <···@opus.nextel.no> wrote:
>Barry Margolin <······@bbnplanet.com> writes:
>
>>
>> In article <··········@goliath.newsfeeds.com>,
>> Janos Blazi <······@netsurf.de> wrote:
>> >What I do not understand is this: OO code may be partly reusable or not. But
>> >which (even theretical) advantage does it offer versus a traditional library
>> >that may use structures instead os "objects".
>>
>> I believe the advantages were expected to come from subclassing and
>> inheritance. If you're implementing something that's "almost like X",
>> rather than copying X's code and modifying it, you make a subclass of X.
>> This way, if changes are made to X's implementation (e.g. performance
>> improvements, bug fixes), your subclass automatically reaps the benefits
>> immediately -- you don't have to copy the new implementation and merge your
>> changes into it again.
>
>But most OO systems has rules prohibiting changes unless the
>superclass explicit allows it. Normally the only thing that can be
>redifined are functions that are declared to be virtual/generic.
>That means classes can only be used in the ways that the author has
>expected in advance.
That's true. It's not a panacea, which is why even with OO we've never
seen the explosion in software reuse that was predicted. OO provides a
better technology to support reuse, but it still depends on people to
design the components properly for this.
Note, however, that you can add *additional* generic functions when
subclassing in most OO systems. So if "almost like X" means "like X plus
it also does Y", it's pretty easy to implement without requiring the
superclass author to have expected it.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Tim Bradshaw
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <ey3ogamp348.fsf@cley.com>
* Janos Blazi wrote:
> What I do not understand is this: OO code may be partly reusable or not. But
> which (even theretical) advantage does it offer versus a traditional library
> that may use structures instead os "objects".
I think the idea is that inheritance is a win. If you want something
that is like an x but a bit different, then instead of finding an
implementation of an x and taking a copy then modifying all the code
&c, you can find an x and then subclass it. That way when someone
soups up x your program breaks immediately rather than next time you
merge their changes in the editor, which is a great advantage as it
enables you to spend more time hacking and less doing useful work.
--tim
In article <··········@goliath.newsfeeds.com>,
"Janos Blazi" <······@netsurf.de> wrote:
> What I do not understand is this: OO code may be partly reusable or
not. But
> which (even theretical) advantage does it offer versus a traditional
library
> that may use structures instead os "objects".
Hi,
There needn't be any difference - for example, many libraries may
already be written in an OO manner, even though they don't use an OO
language.
It's quite common in large C libraries (eg openSSL) to use structures
that include pointers to functions that operate on those same
structures. Apart from inheritance, this is more-or-less C++ without
the syntactic sugar.
To a large extent (IMHO) object oriented languages (it's especially
clear with C/C++) simply aid this approach (especially debugging).
Personally I enjoy using Java (and C, in the style above) and am also
enjoying learning functional programming. Both styles seem to take
quite some time to become proficient at (again, IMHO).
Cheers,
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
"Janos Blazi" <······@netsurf.de> writes:
> What I do not understand is this: OO code may be partly reusable or not. But
> which (even theretical) advantage does it offer versus a traditional library
> that may use structures instead os "objects".
The reason to use OO is not because of reuse, but because it lets the
programmer describe more powerful abstractions in a more succinct way.
This lets one write clearer, simpler code which is potentially easier to
understand and maintain.
Another reason is that often OO languages have stricter type checking (whether
static or dynamic), allowing the programmer to get more help from the compiler
or interpreter when "objects" are misused.
Yet another reason is that object types or "classes" often provide namespaces,
allowing one to name methods and data related to a kind of object without
clashing with names for another kind of object.
The end result is that OO languages provide better tools for writing more
robust software.*
For example, imagine a system that makes use of THING objects. All THINGs agree
to be able to do THIS and THAT. For most of the system, whenever a THING is
encountered, one can safely ask it to do THIS and THAT without concern for the
kind of THING it is. THING1, a kind of THING, might implement THIS differently,
but the rest of the system, in general, will not care. THING2 might implement
it differently again.
This kind of ability allows the different parts of the system to be defined in
a more orthogonal fashion. Without OO abilities, the system, whenever a THING
is encountered, would have to be able to deal with all possible kinds of
THINGs. If one defines a new kind of THING, the whole system has to be
revisited, and special code added for the new kind whereever THINGs are
processed.
Now one can implement dispatching and inheritance mechanisms in non-OO
languages, but that is cumbersome. With an OO language, these mechanisms are
already implemented for you, and are verified by the compiler. The source code
can express the solution more directly, since the OO mechanisms are implicit in
the language instead of needing to be in the code.
*Note: OO lets *potentially* better software be written. Like any other
paradigm it can be abused and have horribly confusing results. C++ is a supreme
example of an "OO" language where gorgeous powerful clean OO code can written
so that the compiler really works for you, and yet with the slightest misuse of
low level features (pointers!) everything comes crashing down *real* fast.
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Robert Monfera
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <3886A897.BC8A4E4@fisec.com>
Ray Blaak wrote:
> [...] object types or "classes" often provide namespaces,
> allowing one to name methods and data related to a kind of object
> without clashing with names for another kind of object.
It is true, but this is not inherent in OOP and is only true with the
message passing style. In fact, this is an exploitation of the ability
to dispatch on one object, which is otherwise a limitation compared to
multiple argument dispatch. As your example seems to suggest you are
used to the message passing style (we ask an object to do things to
itself), maybe you would find the generic function approach (we perform
the operation involving 0 or more objects) refreshing.
If name clashes are avoided the way you describe, isn't there a risk of
confusion when a human wants to understand the code (i.e., conceptually
separating identically named function)? Do you exploit this feature
yourself? (I think I prefer larger units of namespace granularity than
a class + its subclasses).
Regards
Robert
In article <················@fisec.com>,
Robert Monfera <·······@fisec.com> wrote:
> Ray Blaak wrote:
> > [...] object types or "classes" often provide namespaces,
> > allowing one to name methods and data related to a kind of object
> > without clashing with names for another kind of object.
>
> It is true, but this is not inherent in OOP and is only true
> with the message passing style.
Yes indeed. When it exists, though, I find it useful. Some
languages completely separate their OO abilities from namespaces,
which is also perfectly fine. Ada and Perl, for example, use
packages.
> As your example seems to suggest you are used to the message
> passing style (we ask an object to do things to itself), maybe
> you would find the generic function approach (we perform the
> operation involving 0 or more objects) refreshing.
I would be interested in some pointers describing it. Is this
approach what CLOS uses? Is it essentially multi-way dispatching
depending on all of the objects involved?
> If name clashes are avoided the way you describe, isn't there a
> risk of confusion when a human wants to understand the code
> (i.e., conceptually separating identically named function)?
In my experience, not at all. In fact I rely on it (namespaces,
that is, though not necessarily *class* namespaces).
For example, say I have an object that I want to be able to
display on the screen. I could define a Draw method for it. It
would be a major drag if that caused a name-clash with some
pre-existing Draw method, say from one in the windowing system.
When reading source code, I do not get confused about similar
names. I would guess behaviour based on the method name, but
given that I *always* look at variable/object definitions to know
what I am dealing with (how can you not?), the confusion never
arises in practice.
I suppose this is because I tend to use statically typed
languages more. I can see confusion arising more easily in Lisp,
because then it would be possible to have the same code get
objects of a different class, yet still be able to invoke a
method of the same name.
> (I think I prefer larger units of namespace granularity than a
> class + its subclasses).
Namespaces are one of the best inventions in computer science,
and they most certainly should not be limited to classes.
In my opinion, one should have at the very least some sort of
packaging or module construct (nested namespaces must be
allowed!) first. Then you can have arbitrary namespace
granularity.
If class namespaces also exist, that is just an extra bonus.
Cheers,
Ray Blaak
·····@infomatch.com
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Robert Monfera
Subject: Re: Entirely off-topic (is OO any good)
Date:
Message-ID: <3888CE49.90CE7F23@fisec.com>
·····@infomatch.com wrote:
> Ada and Perl, for example, use
> packages.
So does Common Lisp.
> I would be interested in some pointers describing it. Is this
> approach what CLOS uses? Is it essentially multi-way dispatching
> depending on all of the objects involved?
Paul Graham's ANSI Common Lisp has an introductory section, which can
also be found in the ACL Lite tutorial, but you got it right. For
example, I used it to render HTML: the formatting attributes of a cell
may depend on the row, column, value or some other property of the cell
(not all formatting attributes can be applied to rows and columns).
Another example is a kind of object repository: to select the method,
the generic function has to know not only the class of the object to be
loaded/saved, but also the class of the database (file, memory, ODBC).
The use of :before, :after and :around methods, as well as
(call-next-method) may result in very compact code, which resembles (and
maybe is) rule-based computing - perhaps each method is very short, it's
their combination is what makes them powerful.
Another advantage is that generic functions ensure consistency across
large packages and applications, as usually their number is relatively
low. It brings about a two-level definition scheme - you define the GF
and document what it does _conceptually_ and what required or optional
parameters it has. Then you go on and worry about the _implementation_
- for objects of classes X and Y do this. For objects of classes A and
B do that. For objects of classes A and whatever (except B) do yet
another thing. For objects of classes A and whatever (including B)
perform this :after method.
You can find pointers to books on CL and CLOS, as well as CL
implementations (in case you don't use one already) on
http://www.alu.com .
> For example, say I have an object that I want to be able to
> display on the screen. I could define a Draw method for it. It
> would be a major drag if that caused a name-clash with some
> pre-existing Draw method, say from one in the windowing system.
Aren't the windowing system and your application in different packages?
Conversely, you may be a class which defined a Draw method, and another
one which defined a Paint method - to do essentially the same thing!
This would make things like writing a loop to display numerous objects
difficult.
If you obtain or develop both classes, you may argue both would use the
same naming, because they are likely to be part of the same package or
module. If you get them from different sources, or you develop one of
the classes and obtain the other, chances are you rearrange definitions
to be part of one integrated module (e.g., you would subordinate one of
the classes to a superclass of the other class, or just rename one of
the method).
No matter which way we look, the result is that your method names will
be determined at the module level. People are in OOP because it
exploits similarities amongst things and behaviors (i.e., functions).
I admit there is a special case, which may be more frequent with
languages featuring message passing only - when a package corresponds to
only one class and its subclasses. For this case, it is pointless to
talk about what the right level is, but even then a common namespace
could filter out undesirable things like reusing the same name for
different purposes in subclasses of the same root class. If not for
some other reason, a name collision may indicate a previously
unexploited opportunity to generalize or unify?
Another reason I'm in defense of name spaces bigger than classes is that
class-level namespaces are not possible to fathom with multiple argument
dispatch :-)
Robert