Speaking of strings...

[Harlow]

"Jason" <jason@hotmail.com> wrote:
>
>Let me be more specific on some of these things:
>
>Functions for manipulating strings:
> Mid$
> Left$
> UCase$
> LCaseS
> StrConv
>
>Why are all these things functions? Because they were functions in Basic
>20 years ago! My TRS80 Model 100 supports all these functions, using the
>original version of Microsoft Basic.
>
>Strings are objects. Files are objects. But in VB-classic, they are data
>structures, or something that is not quite an object. Legacy.
>

Can anyone tell me why the .NET String class is Sealed (C# term, I don't
know what the VB.NET equivalent is)? It does not have a Left method for example,
so why not inherit from the String class and add your own Left functionality?
I'll tell you why, because it is Sealed. You cannot inherit from it. Is there
something I am missing?

- Harlow.

p.s. - Yes, I know the String class has a SubString method, but it throws
an exception if you go out of range. The Left implementation would give you
as many characters as are available without requiring that the caller know
how many are there.

[blob]

>Can anyone tell me why the .NET String class is Sealed (C# term, I don't
>know what the VB.NET equivalent is)? It does not have a Left method for
example,
>so why not inherit from the String class and add your own Left functionality?
>I'll tell you why, because it is Sealed. You cannot inherit from it. Is
there
>something I am missing?

Why inherit? Why not use containment and add your Left function. It would
wind up something similar to private inheritance in C++. This is what happens
when VB programmers attempt OO. Inherit, inherit, inherit. Come on you
(so-called) OO VB developers, let me have it.

[Jason]

"Harlow" <harlow@nospam.com> wrote:
>Can anyone tell me why the .NET String class is Sealed (C# term, I don't
>know what the VB.NET equivalent is)? It does not have a Left method for
example,
>so why not inherit from the String class and add your own Left functionality?
>I'll tell you why, because it is Sealed. You cannot inherit from it. Is
there
>something I am missing?
>
> - Harlow.

Probably a speed or size optimization. No inheritance, no virtual function-pointer
table lookups. Maybe for consistency, since you can't inherit from any of
the basic data types.

Java does the same thing.

[Vinay]

"Harlow" <harlow@nospam.com> wrote:
>
>
>Can anyone tell me why the .NET String class is Sealed

IMO,
String is special class in a sense that programmers want to use it as a value
type. And compilers and CLR also recognize string as special class. CLR has
lot of optimizations for strings and many of them r possible because CLR
knows strings are immutable (only access possible is read access). And thats
why the class is sealed so that no one should inherit it and make it read-write
turning CLR's main assumption to shreds.

-Vinay.

[Mike Mitchell]

On 4 Oct 2002 21:53:58 -0700, "Vinay" <vinayc@angelfire.com> wrote:

>IMO,
>String is special class in a sense that programmers want to use it as a value
>type. And compilers and CLR also recognize string as special class. CLR has
>lot of optimizations for strings and many of them r possible because CLR
>knows strings are immutable (only access possible is read access). And thats
>why the class is sealed so that no one should inherit it and make it read-write
>turning CLR's main assumption to shreds.


I'd like to know one good reason why a VB.Net string has to be an
object.

MM

[Larry Serflaten]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>
> I'd like to know one good reason why a VB.Net string has to be an
> object.

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. These are common methods
mind you, used regularly, so it makes sense to have them as methods on the
class. So, then, if they made String a value type, that would mean every
call to one of its methods would included the boxing of the value so that
the methods could be called. It could be a dramatic performance hit
if every method had to check for, or create, a boxed object.

That could be a major reason right there.

LFS

[Mike Mitchell]

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?

> 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?

> So, then, if they made String a value type, that would mean every
>call to one of its methods would included the boxing of the value so that
>the methods could be called.

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

> It could be a dramatic performance hit
>if every method had to check for, or create, a boxed object.

Of course. Not with a function though. With strings like they used to
be.

>That could be a major reason right there.

Or not.

MM

[Larry Serflaten]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote

>
> Why? What is better about a method than a function? Why?


Wise up Mike. OOP is here to stay. If you want to learn the
advantages, then I suggest you take it upon yourself to get educated.
I am not going rehearse explainations you can find yourself.

LFS

[Mike Mitchell]

On Sun, 6 Oct 2002 06:08:05 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:

>"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
>
>>
>> Why? What is better about a method than a function? Why?
>
>
>Wise up Mike. OOP is here to stay. If you want to learn the
>advantages, then I suggest you take it upon yourself to get educated.
>I am not going rehearse explainations you can find yourself.

But I am trying to take it upon myself to get educated. You just won't
tell me what is better about a method! Why keep it a secret? If you
know, just tell me. Then we'd both know! How about you'll tell me if I
give you a dollar?

MM

[Larry Serflaten]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
> >
> >Wise up Mike. OOP is here to stay. If you want to learn the
> >advantages, then I suggest you take it upon yourself to get educated.
> >I am not going rehearse explainations you can find yourself.
>
> But I am trying to take it upon myself to get educated. You just won't
> tell me what is better about a method! Why keep it a secret? If you
> know, just tell me. Then we'd both know! How about you'll tell me if I
> give you a dollar?

Do you still have your mommy tie your shoes too?

This is all I am going to offer:
http://www.google.com/search?hl=en&i...&q=oop+ooa+ood


LFS

[W.E. (Bill) Goodrich, PhD]

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

> "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote

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

LOL!!! Are you really THAT naive? That would help explain a lot.
No, Larry, OOP is NOT "here to stay" in any meaningful sense. Any
more than Knuth-style "Strict Structured Programming" was here to
stay (despite the equally adamant - and naive - claims of its
supporters). Just as tattered fragments of the '70s fad retain the
name and little else, a few more years' time will see your beloved
OOP in a similar state.

And since you are so found of links:

http://www.geocities.com/tablizer/oopbad.htm

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

http://www.paulgraham.com/noop.html

http://www.bluetail.com/~joe/vol1/v1_oo.html


--

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 *
*-----------------------*--------------------------------------------*

[Vinay]

"Larry Serflaten" <serflaten@usinternet.com> wrote:
>"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>>
>> I'd like to know one good reason why a VB.Net string has to be an
>> object.
>
>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. These are common methods
>mind you, used regularly, so it makes sense to have them as methods on the
>class. So, then, if they made String a value type, that would mean every
>call to one of its methods would included the boxing of the value so that
>the methods could be called. It could be a dramatic performance hit
>if every method had to check for, or create, a boxed object.
>
>That could be a major reason right there.
>
>LFS
>

I was not aware of that value types has to be boxed for method invokation.
Any quick links to documentation?
Anyway, IMO typically one will want strings on heap and not on stack so why
bother to make it value type. As far as programmers' perception, compliers
do make it appear like value type.

BTW, I don't think .NET strings r different that vb6 strings (BSTR). Both
were immutable and heap based. Although .NET strings are objects they r perceived
as value types same as in VB.

-Vinay

[Miha Markic]

> I'd like to know one good reason why a VB.Net string has to be an
> object.
>
> MM

Since every class in .NET is dervied from Object class you instantly get
Object functionality.
Also, there is reflection, serialization, etc.
Why would you have functions since they work only with strings and thus
belong to strings anyway?

--
Miha
www.spin.si/www/eng

[Brian S]

For every 4 of your links there are 100 pro OO articles from "recognized"
and "respected" authorities on the topic. Not these whipped up articles
by someone who says "Why OO sucks". Not to mention you got all of these
links from the same page.

>http://www.geocities.com/tablizer/oopbad.htm
This seems to be from some guy in his basement who does FoxPro. So what?

>http://iraf.noao.edu/iraf/web/ADASS/.../cogginsj.html
1996 for gods sake. Anything a little more recent?


>http://www.paulgraham.com/noop.html
I love articles like this that have this statement -- "From some of the best
programmers I know". I am the best programmer I know. So what?


>http://www.bluetail.com/~joe/vol1/v1_oo.html
This is the best of them all. "Why OO Sucks". Man, that has got to be quality
stuff from a qualified person.

[Larry Serflaten]

"Vinay" <vinayc@angelfire.com> wrote
>
> "Larry Serflaten" <serflaten@usinternet.com> wrote:
> >class. So, then, if they made String a value type, that would mean every
> >call to one of its methods would included the boxing of the value so that
> >the methods could be called.
>
> I was not aware of that value types has to be boxed for method invokation.
> Any quick links to documentation?

Thanks for the challenge, I misunderstood the statements I read to the effect:

"Boxing and unboxing allow any type to be treated as an object." I've seen
that in many places, one such example is found on a page about value types.
(http://msdn.microsoft.com/library/de...ClassTopic.asp)

After looking for documentation to specifically mention the boxing or unboxing,
I find that it only applies when accessing the methods available to all objects
(those implemented for the Object interface):
http://msdn.microsoft.com/library/de...vclrf__box.asp

LFS