Speaking of strings...

"W.E. (Bill) Goodrich,
>
> > > >Wise up Mike. OOP is here to stay.
>
> LOL!!! Are you really THAT naive? That would help explain a lot.

Your links explained a lot about how you think as well. Of the 4 you
posted only 1 was from a (outdated) source most would consider reputable:

> http://iraf.noao.edu/iraf/web/ADASS/.../cogginsj.html

Even there it states:


There are three main weaknesses to the current formulation of object-oriented design and programming.

First, OOP tends to encourage bottom-up design...
Second, OOP tends to encourage toolkits of tiny classes...
Third, OOP provides no good answer to the problems of asynchronous I/O or concurrent processing, as occurs in user interfaces.

It looks like he is saying its not a good design because it can be misused, with maybe one shortfall
in concurrent processing. Those are hardly make or break technology busters. Developer discipline
is not the job of the language, and I/O and multi threading are being addressed, (FileStreams and
Threads).

Perhaps you should re-read this entire section because it refutes the idea you intended it to show:

3.3. Can Object-Oriented Programming Have a Long-term Strategic Impact on Software Development? Yes.

"OOP will not make developing your first project faster, nor your second. But with a good strategic core class library, later
applications within the same family will be developed quicker and more reliably."

LFS

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3da1b1c5@10.1.10.29...

>
> 3.3. Can Object-Oriented Programming Have a Long-term Strategic Impact on
Software Development? Yes.
>
> "OOP will not make developing your first project faster, nor your second.
But with a good strategic core class library, later
> applications within the same family will be developed quicker and more
reliably."

But that is an argument in favor of code re-use, not OOP. Exactly the same
can be said of the re-use of tested and working procedural code.

Now, I'm not trying to suggest that OOP has no uses, it is just that your
quote does not demonstrate its utility for the purpose you are claiming.

One of the main complaints coming from Dan and others was that the language
changes effectively prohibit the re-use of such code developed in earlier
versions of VB. Since most of the syntax changes were not necessary for the
purpose of making the language more OO, it seems to me that it is a valid
question whether the sum total of the changes between VB6 and VB.NET have
improved productivity for developers or teams extending existing
applications or in possession of substantial VB6 code libraries.

--
Regards
Jonathan West

On Sun, 06 Oct 2002 11:15:31 +0100, Mike Mitchell <kylix_is@yahoo.co.uk> wrote:

¤ On Sat, 5 Oct 2002 19:39:51 -0500, "Larry Serflaten"
¤ <serflaten@usinternet.com> wrote:
¤
¤ >How about because there were many commands in VB that only worked
¤ >on strings (Left, Right, UCase, LCase, Trim, etc) which would be better
¤ >if they were simply methods of the string class.
¤
¤ Why? What is wrong with functions like Left$, Trim$ etc?

Nothing. They're still there if you want to use them as you have before. In, addition they've been
methods of a class since VBA has been around so this isn't new in VB.NET. The fact that they are
also know as functions is meaningless in this context.

¤ Or use a function. Again, why is a String now an object? Why?

All data types are objects. Why is this a problem for you?


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

Mike Mitchell wrote:

> Why? What is wrong with functions like Left$, Trim$ etc?

Nothing. They still exist AFAIK.

>> These are common methods
>> mind you, used regularly, so it makes sense to have them as methods
>> on the class.
>
> Why? What is better about a method than a function? Why?

It is intuitively linked to the type (and data) it operates on. Given an
instance of a String for instance, the IDE can prompt you about all sorts of
things you can do with it or to it.......more productive than scouring the
help pages for functions that can be applied to strings.

> Again, why is a String now an object? Why?

A String is a datatype. All datatypes in .NET are objects (or can be treated
as such).

HTH!

Kunle

On Sun, 6 Oct 2002 15:17:27 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:

>Do you still have your mommy tie your shoes too?

No, she died. So I wear slip-ons now.

MM

On Mon, 7 Oct 2002 18:00:40 +0100, "Jonathan West" <jwest@mvps.org>
wrote:

>One of the main complaints coming from Dan and others was that the language
>changes effectively prohibit the re-use of such code developed in earlier
>versions of VB. Since most of the syntax changes were not necessary for the
>purpose of making the language more OO, it seems to me that it is a valid
>question whether the sum total of the changes between VB6 and VB.NET have
>improved productivity for developers or teams extending existing
>applications or in possession of substantial VB6 code libraries.

I'm still waiting for the .Netizens to define and quantify their
so-called improved productivity. (They drove that other thread
specifically about productivity off into never-never land.) Beats me
how it can be more productive to have to rewrite maybe millions of
lines of perfectly working code in order to then see greater
productivity in .Net. As for OOP in VB.Net, if the programmers of
around 70% of classic VB apps never wrote a class, i.e. to them OOP
was about as interesting and useful as a chocolate dildo, how do the
..Netizens imagine that these programmers will suddenly see the light
and start doing everything in OOP? It ain't gonna happen!

MM

On Mon, 07 Oct 2002 12:45:04 -0500, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>¤ Why? What is wrong with functions like Left$, Trim$ etc?
>
>Nothing. They're still there if you want to use them as you have before. In, addition they've been
>methods of a class since VBA has been around so this isn't new in VB.NET. The fact that they are
>also know as functions is meaningless in this context.

But why is a VB.Net string an object now? What was wrong with
traditional VB strings?

>¤ Or use a function. Again, why is a String now an object? Why?
>
>All data types are objects. Why is this a problem for you?

It's no good just telling me they're objects! I know that. My question
is, why? Specifically, a string: - why does it need to be an object
now? It never used to be. That is the problem. A VB/QuickBASIC string
has been since like forever just a sequence of bytes with a string
descriptor telling B.A.S.I.C. where it is and how long. Why change it?
What's the advantage now?

MM

On Mon, 7 Oct 2002 19:06:20 +0100, "Kunle Odutola"
<kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

>Mike Mitchell wrote:
>
>> Why? What is wrong with functions like Left$, Trim$ etc?
>
>Nothing. They still exist AFAIK.

So, if there's nothing wrong with functions, why introduce methods?
Why make strings objects? Why? What's the point?

>>> These are common methods
>>> mind you, used regularly, so it makes sense to have them as methods
>>> on the class.
>>
>> Why? What is better about a method than a function? Why?
>
>It is intuitively linked to the type (and data) it operates on. Given an
>instance of a String for instance, the IDE can prompt you about all sorts of
>things you can do with it or to it.......more productive than scouring the
>help pages for functions that can be applied to strings.

What is the advantage of it being intuitively linked? Is it only so
that the IDE can prompt me? Surely that is overkill, since I didn't
forget Left$ or Mid$ in classic VB/QuickBASIC after using them a few
times. Likely as not, I wouldn't forget a method call either. And, in
fact, sometimes Intellisense is a pain in the butt when it keeps
popping up even though I know *exactly* what I want to type next. So
is there no other advantage why a string now has to be an object?

>> Again, why is a String now an object? Why?
>
>A String is a datatype. All datatypes in .NET are objects (or can be treated
>as such).

This is what LFS said, too! I *know* they're objects, but the question
is, why? What's the point?

>HTH!

Well, it didn't!

MM

No need to rewrite existing code libraries. Keep them in VB6 and use them
there. Do new development in VB.NET. To me, that makes the best sense of
all possibilities. As for improved productivity for developers, that
should come from learning and using VB.NET and the improvements the
Framework brings to programming for Windows. In other words,
use the right tool for the right job.
james


"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:2en3qu8iqdlrvcfad6k697h8ff2j8sila3@4ax.com...
> On Mon, 7 Oct 2002 18:00:40 +0100, "Jonathan West" <jwest@mvps.org>
> wrote:
>
> >One of the main complaints coming from Dan and others was that the
language
> >changes effectively prohibit the re-use of such code developed in earlier
> >versions of VB. Since most of the syntax changes were not necessary for
the
> >purpose of making the language more OO, it seems to me that it is a valid
> >question whether the sum total of the changes between VB6 and VB.NET have
> >improved productivity for developers or teams extending existing
> >applications or in possession of substantial VB6 code libraries.
>
> I'm still waiting for the .Netizens to define and quantify their
> so-called improved productivity. (They drove that other thread
> specifically about productivity off into never-never land.) Beats me
> how it can be more productive to have to rewrite maybe millions of
> lines of perfectly working code in order to then see greater
> productivity in .Net. As for OOP in VB.Net, if the programmers of
> around 70% of classic VB apps never wrote a class, i.e. to them OOP
> was about as interesting and useful as a chocolate dildo, how do the
> .Netizens imagine that these programmers will suddenly see the light
> and start doing everything in OOP? It ain't gonna happen!
>
> MM

In article <3da1b1c5@10.1.10.29>,
"Larry Serflaten" <serflaten@usinternet.com> writes:

> "W.E. (Bill) Goodrich,

> > > > >Wise up Mike. OOP is here to stay.

> > LOL!!! Are you really THAT naive? That would help explain a lot.

> Your links explained a lot about how you think as well.

Not in the way you think. They merely point to areas of discontent,
similar to the pattern which brought about the downfall of the
academic fad of Strict Structured Programming.

> Of the 4 you posted only 1 was from a (outdated) source most would
> consider reputable:

> > http://iraf.noao.edu/iraf/web/ADASS/.../cogginsj.html

Which you missed the significance of (big surprise). Coggins went on
to become one of the advocates of The Next Big Thing In Computer
Science: Aspect Oriented Programming (AOP). And since you are so
found of posting searches:

http://citeseer.nj.nec.com/cs?q=aop&...Documents&cs=1

ALL from "reputable sources" by your apparent standards. It is clear
that OOP is now going through exactly the same process that destroyed
the prominence of Strict Structured Programming. As is so often the
case, history is repeating itself. And to cite an old saw: those who
fail to learn the lessons of history are doomed to repeat them. Your
precious OOP is not "here to stay" - it is already on its way out.
What are you doing to leave that outdated fad behind and move on to
the more modern AOP? Do you even have any concept what AOP is? How
much time are you spending toward the mastery of the newer AO
languages?

I watched Strict Structured Programming - and its obnoxiously self
righteous acolytes - go down the same drain that yawns before OOP (and
its similar supporters). Your sad little claim that "OOP is here to
stay" would seem to tell us a lot about how you think, and where you
are headed.

And throughout all the fads, the time honored principles of modular
programming have (when applied) lead to code which is more secure,
more readable and maintainable, and generally more efficient and
effective than that of the fad approaches.

[...]

> "OOP will not make developing your first project faster, nor your
> second. But with a good strategic core class library, later
> applications within the same family will be developed quicker and
> more reliably."

Interesting that you leave out the part where he acknowledged that the
same could have been said of "traditional procedure libraries" as well.

And as Jonathan pointed out, the loudest complaint about VB.NET is the
extent to which it negatively impacts such libraries. And the
precedent for Micro$oft following the same destructive pattern in the
future.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote
>
> > > > > >Wise up Mike. OOP is here to stay.
>
> And as Jonathan pointed out, the loudest complaint about VB.NET is the
> extent to which it negatively impacts such libraries.

I wasn't responding to any of that, Mike asked about strings, and such is the
name of the subject.

LFS

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in
news:3DA1F8EE.377497A5@netzero.net:

[...]
>
> Which you missed the significance of (big surprise). Coggins went on
> to become one of the advocates of The Next Big Thing In Computer
> Science: Aspect Oriented Programming (AOP). And since you are so
> found of posting searches:
>
> http://citeseer.nj.nec.com/cs?q=aop&...Documents&cs=1
>
> ALL from "reputable sources" by your apparent standards. It is clear
> that OOP is now going through exactly the same process that destroyed
> the prominence of Strict Structured Programming. As is so often the
> case, history is repeating itself. And to cite an old saw: those who
> fail to learn the lessons of history are doomed to repeat them. Your
> precious OOP is not "here to stay" - it is already on its way out.
> What are you doing to leave that outdated fad behind and move on to
> the more modern AOP? Do you even have any concept what AOP is? How
> much time are you spending toward the mastery of the newer AO
> languages?
>
> I watched Strict Structured Programming - and its obnoxiously self
> righteous acolytes - go down the same drain that yawns before OOP (and
> its similar supporters). Your sad little claim that "OOP is here to
> stay" would seem to tell us a lot about how you think, and where you
> are headed.
>
> And throughout all the fads, the time honored principles of modular
> programming have (when applied) lead to code which is more secure,
> more readable and maintainable, and generally more efficient and
> effective than that of the fad approaches.
>
Then what evidence is there to contradict that both AOP and MP are not
just fads too, albeit in different phases of fad-ness and with varying
fad longevity?
Indeed, what reason is there to apply any kind of methodology or
programming modality at all, if all you can be sure of is the demise of
the principles?
I can't but hear faint echoes of the criticism raised by Newtonian
physicists against the theory of relativity. Or the criticism raised by
Einstein against quantum physics. Yet all three of them represent views
of nature that are valid for solving a certain domain of problems, but
inappropriate for others.

With regard to "obnoxiously self righteous acolytes": Pot, kettle, black?

--
Rune Bivrin
- OOP since 1989
- SQL Server since 1990
- VB since 1991

<snip>
>
> http://citeseer.nj.nec.com/cs?q=aop&...Documents&cs=1
>
> ALL from "reputable sources" by your apparent standards. It is clear
> that OOP is now going through exactly the same process that destroyed
> the prominence of Strict Structured Programming. As is so often the
> case, history is repeating itself. And to cite an old saw: those who
> fail to learn the lessons of history are doomed to repeat them. Your
> precious OOP is not "here to stay" - it is already on its way out.
> What are you doing to leave that outdated fad behind and move on to
> the more modern AOP? Do you even have any concept what AOP is? How
> much time are you spending toward the mastery of the newer AO
> languages?
>

I'm not so sure that AOP is here to *replace* OOP but maybe to *enhance* it.
One of the nice things about AOP is that it is supposed to work with
structured as well as OOP based methodologies. Most of the current work
seems to be geared towards OOP at this time. Your own cite pretty much seems
to validate that point. A quick look at the current tools available also
seem to validate it as well.

http://www.aosd.net/tools.html

Most seem to be based upon Java, but there are a couple related to Smalltalk
and even a C# entry in the list. I'm sure this isn't the only list and that
these are not the only tools, but the pattern seems clear.

I'm sure you would like OOP to disappear into the sunset for whatever
reasons you may have, but it is only one of many methods to develop
software. Sometimes it is the best method, other times other methods are
better suited.

Jay

W.E. (Bill) Goodrich, PhD wrote:

> Which you missed the significance of (big surprise). Coggins went on
> to become one of the advocates of The Next Big Thing In Computer
> Science: Aspect Oriented Programming (AOP).

Bill, AOP piggy-backs on existing methodologies including OOP. It does not
replace them. Most AOP implementations have been extensions to OOP languages
such as Java and Smalltalk.

Kunle

Mike Mitchell <kylix_is@yahoo.co.uk> wrote in
news:eho3qu03pv46msn005h3s4lmos7vd4767b@4ax.com:

>>
>>It is intuitively linked to the type (and data) it operates on. Given
>>an instance of a String for instance, the IDE can prompt you about all
>>sorts of things you can do with it or to it.......more productive than
>>scouring the help pages for functions that can be applied to strings.
>
> What is the advantage of it being intuitively linked? Is it only so
> that the IDE can prompt me? Surely that is overkill, since I didn't
> forget Left$ or Mid$ in classic VB/QuickBASIC after using them a few
> times. Likely as not, I wouldn't forget a method call either. And, in
> fact, sometimes Intellisense is a pain in the butt when it keeps
> popping up even though I know *exactly* what I want to type next. So
> is there no other advantage why a string now has to be an object?
>
On occasions, there have been questions raised by certain members of this
community whether VB.NET is easier or harder to learn than VB6 for a
novice. This may be one of the issues that contribute to the answer...

--
Rune Bivrin
- OOP since 1989
- SQL Server since 1990
- VB since 1991