String Functions

Based on what I've heard so far, VB7 still retains anachronisms like Trim,
Left, Mid, etc. Why? Shouldn't all these functions be replaced by the String
object's intrinsic properties and methods?

/Pat

<Patrick Troughton Patrick> wrote in message
news:39aeb0e9$1@news.devx.com...
>
> Based on what I've heard so far, VB7 still retains anachronisms like Trim,
> Left, Mid, etc. Why? Shouldn't all these functions be replaced by the
String
> object's intrinsic properties and methods?

Ho! That would be a lark. The current ruckus about breaking existing code
isn't enough for you? I'm sure they're there for compatibility.

(personally, I'm all for hosing old code entirely for purity's sake, but I
think I'm in the great minority <g>)

See the response to you previous post.

<Patrick Troughton Patrick> wrote in message
news:39aeb0e9$1@news.devx.com...
>
> Based on what I've heard so far, VB7 still retains anachronisms like Trim,
> Left, Mid, etc. Why? Shouldn't all these functions be replaced by the
String
> object's intrinsic properties and methods?
>
> /Pat

Two words...

Backward compatibility.

For those of us that will have to do a lot of rewriting to convert older
apps to VB.Net (or VB?), it's one less thing we have to worry about until we
have the luxury of time to go back and use new methodology.
___________________________
Dan Rhea - Mailto:danr@sirs.com
Windows CD-ROM Programmer
SIRS Mandarin, Inc.
(561) 994-0079 x757
<Patrick Troughton Patrick> wrote in message
news:39aeb0e9$1@news.devx.com...
>
> Based on what I've heard so far, VB7 still retains anachronisms like Trim,
> Left, Mid, etc. Why? Shouldn't all these functions be replaced by the
String
> object's intrinsic properties and methods?
>
> /Pat

Hi Rob --

> > Based on what I've heard so far, VB7 still retains anachronisms like Trim,
> > Left, Mid, etc. Why? Shouldn't all these functions be replaced by the String
> > object's intrinsic properties and methods?
>
> Ho! That would be a lark. The current ruckus about breaking existing code
> isn't enough for you? I'm sure they're there for compatibility.

Heh, "compatibility." That's a good one! <bg>

> (personally, I'm all for hosing old code entirely for purity's sake, but I
> think I'm in the great minority <g>)

Yep. As soon as they break native data types, they might as well just chuck the
entire language, and hose it completely. Absolutely agreed.

Later... Karl
--
http://www.mvps.org/vb

Gee Karl, do I sense a tad bit of sarcasm in your message???

> Yep. As soon as they break native data types, they might as well just
chuck the
> entire language, and hose it completely. Absolutely agreed.
>
> Later... Karl
> --
> http://www.mvps.org/vb
>
>
>
>
>

Hi Jay --

> Gee Karl, do I sense a tad bit of sarcasm in your message???
>
> > Yep. As soon as they break native data types, they might as well just chuck the
> > entire language, and hose it completely. Absolutely agreed.

Heheheh... Think so? <g>

Naw! I really did mean it. It's so hosed as it is, they really ought to just finish
the job, instead of leaving little flecks of birdsh!t here and there, eh? :-)

Later... Karl
--
http://www.mvps.org/vb

Well, I do think they should finish the job. I flamed you a bit on the
listserver (nothing personal), but I think VB needs to take a step in one
direction or the other. The more I look, the more I think that MSFT is still
trying to straddle that fence of an easy tool to use and a powerful
developement tool. I don't think you can have it both ways. Everyone wanted
inheritance. Great, but your point about removing the ptr functions is well
taken. Is there a way to replace that functionality? I say **** the
torpedoes and the marketing geeks that think they are programmers because
they can get a message box to pop up. Allow the unsafe code, allow the
operator overload, allow VB to really become the tool that it's capable of.
All of the old code is already broke, so their isn't anything holding it
back.

OK, I'll step off the soapbox now...

Karl E. Peterson <karl@mvps.org> wrote in message
news:39aee59c@news.devx.com...
> Hi Jay --
>
> > Gee Karl, do I sense a tad bit of sarcasm in your message???
> >
> > > Yep. As soon as they break native data types, they might as well just
chuck the
> > > entire language, and hose it completely. Absolutely agreed.
>
> Heheheh... Think so? <g>
>
> Naw! I really did mean it. It's so hosed as it is, they really ought to
just finish
> the job, instead of leaving little flecks of birdsh!t here and there, eh?
:-)
>
> Later... Karl
> --
> http://www.mvps.org/vb
>
>
>
>
>

We are providing the string functions to offer backwards compatability and
familiarity to Visual Basic users. Most of the Visual Basic Runtime
functions are implemented using the main runtime functions, some are simple
wrappers, others are more complex. For example the Visual Basic versions of
the functions will use the current locale for the application when
performing locale sensitive operations. You are free to use the Visual Basic
functions if you wish, or you can use the functions in the main runtime, or
both, the choice is yours.

Sam

<Patrick Troughton Patrick> wrote in message
news:39aeb0e9$1@news.devx.com...
>
> Based on what I've heard so far, VB7 still retains anachronisms like Trim,
> Left, Mid, etc. Why? Shouldn't all these functions be replaced by the
String
> object's intrinsic properties and methods?
>
> /Pat

Hi Jay,

I agree with a lot of what you're saying here. I can't believe how much
things have changed. I wish I could be there to see the look on the millions
of faces when they open a VB6 project with . Net and (assuming the migration
tools do a good job), open the code they've been working on all week and say
'what the **** is this and who wrote it?'. They might as well have just
changed the name like they did with C#. Please note, I'm really excited
about VB.Net, but it is pretty much a different language. I find it
interesting that they limit functionality so that we don't hurt ourselves,
but that they give us free-threading that's as simple to use as about 4
lines of code.

Getting used to the new data types, particularly where the old name is used
for a new type (Long?) will take a while to get used to.


Should get fun....!


--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com

"Jay Glynn" <jay_glynn@agla.com> wrote in message
news:39af1db9$1@news.devx.com...
> Well, I do think they should finish the job. I flamed you a bit on the
> listserver (nothing personal), but I think VB needs to take a step in one
> direction or the other. The more I look, the more I think that MSFT is
still
> trying to straddle that fence of an easy tool to use and a powerful
> developement tool. I don't think you can have it both ways. Everyone
wanted
> inheritance. Great, but your point about removing the ptr functions is
well
> taken. Is there a way to replace that functionality? I say **** the
> torpedoes and the marketing geeks that think they are programmers because
> they can get a message box to pop up. Allow the unsafe code, allow the
> operator overload, allow VB to really become the tool that it's capable
of.
> All of the old code is already broke, so their isn't anything holding it
> back.
>
> OK, I'll step off the soapbox now...
>
> Karl E. Peterson <karl@mvps.org> wrote in message
> news:39aee59c@news.devx.com...
> > Hi Jay --
> >
> > > Gee Karl, do I sense a tad bit of sarcasm in your message???
> > >
> > > > Yep. As soon as they break native data types, they might as well
just
> chuck the
> > > > entire language, and hose it completely. Absolutely agreed.
> >
> > Heheheh... Think so? <g>
> >
> > Naw! I really did mean it. It's so hosed as it is, they really ought
to
> just finish
> > the job, instead of leaving little flecks of birdsh!t here and there,
eh?
> :-)
> >
> > Later... Karl
> > --
> > http://www.mvps.org/vb
> >
> >
> >
> >
> >
>
>

Hi Sam,

Can you tell us if there is a performance difference between the two?

--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com

"Sam Spencer" <samsp@microsoft.com> wrote in message
news:39af25d6$1@news.devx.com...
> We are providing the string functions to offer backwards compatability and
> familiarity to Visual Basic users. Most of the Visual Basic Runtime
> functions are implemented using the main runtime functions, some are
simple
> wrappers, others are more complex. For example the Visual Basic versions
of
> the functions will use the current locale for the application when
> performing locale sensitive operations. You are free to use the Visual
Basic
> functions if you wish, or you can use the functions in the main runtime,
or
> both, the choice is yours.
>
> Sam
>
> <Patrick Troughton Patrick> wrote in message
> news:39aeb0e9$1@news.devx.com...
> >
> > Based on what I've heard so far, VB7 still retains anachronisms like
Trim,
> > Left, Mid, etc. Why? Shouldn't all these functions be replaced by the
> String
> > object's intrinsic properties and methods?
> >
> > /Pat
>
>

Backwards compatability was thrown out the window a long time ago. Why not
go all the way and do it right?

/Pat

"Sam Spencer" <samsp@microsoft.com> wrote:
>We are providing the string functions to offer backwards compatability and
>familiarity to Visual Basic users. Most of the Visual Basic Runtime
>functions are implemented using the main runtime functions, some are simple
>wrappers, others are more complex. For example the Visual Basic versions
of
>the functions will use the current locale for the application when
>performing locale sensitive operations. You are free to use the Visual Basic
>functions if you wish, or you can use the functions in the main runtime,
or
>both, the choice is yours.
>
>Sam
>
><Patrick Troughton Patrick> wrote in message
>news:39aeb0e9$1@news.devx.com...
>>
>> Based on what I've heard so far, VB7 still retains anachronisms like Trim,
>> Left, Mid, etc. Why? Shouldn't all these functions be replaced by the
>String
>> object's intrinsic properties and methods?
>>
>> /Pat
>
>

Hi Jay --

> Well, I do think they should finish the job.

Agreed.

> I flamed you a bit on the listserver (nothing personal),

Ah, yes, that _was_ you, wasn't it? <g> Hey, flame on. Just be accurate.

(That list's just entirely too uptight, isn't it?)

> but I think VB needs to take a step in one
> direction or the other.

Agreed.

> The more I look, the more I think that MSFT is still
> trying to straddle that fence of an easy tool to use and a powerful
> developement tool. I don't think you can have it both ways.

I think you can, and the fence straddling is the problem. Contradiction? Nope.
Sitting on a fence *hurts*, especially if you have one leg on each side. There's no
reason they can't have a full-blown, balls-out language that's still easy to ramp up
with. They had the beginnings of it with VB5/6, but seem to be heading the other
direction with 7. I view the attitude above as a simple lack of imagination and/or
courage.

> Everyone wanted inheritance.

Yeah, go figure, huh? <g>

> Great, but your point about removing the ptr functions is well
> taken.

Didja notice how they *all* shut-up (heh, reviewing the list, you too! <g>) everytime
that question was (re)raised? Kept hearing the BS throw-away line, "there's still
the API!" Well, what the heck good is that, without the ability to pass pointers
around, hmmm? No one's answering that, yet.

> Is there a way to replace that functionality? I say **** the
> torpedoes and the marketing geeks that think they are programmers because
> they can get a message box to pop up. Allow the unsafe code, allow the
> operator overload, allow VB to really become the tool that it's capable of.

Yes!

> All of the old code is already broke, so their isn't anything holding it
> back.

AMEN, Brother!!!

> OK, I'll step off the soapbox now...

No, please don't. It suits you. ;-)

(Just keep that flamethrower pointed at MS, rather than the guy who poked you until
you pulled the trigger. <bg>)

Later... Karl
--
http://www.mvps.org/vb

Hi Sam --

> We are providing the string functions to offer backwards compatability and
> familiarity to Visual Basic users.

Forgive the group, but you must realize just how disingenuous that sounds, right?
Please inform the marketeers that this message just ain't gonna fly with the masses.

> Most of the Visual Basic Runtime
> functions are implemented using the main runtime functions, some are simple
> wrappers, others are more complex. For example the Visual Basic versions of
> the functions will use the current locale for the application when
> performing locale sensitive operations.

Now _this_ is interesting. Will these differences be highlighted in the docs? This
is very important information to be aware of!

Thanks... Karl
--
http://www.mvps.org/vb

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39afdd15@news.devx.com...
> > For example the Visual Basic versions of
> > the functions will use the current locale for the application when
> > performing locale sensitive operations.
>
> Now _this_ is interesting. Will these differences be highlighted in the
docs? This
> is very important information to be aware of!

I was asked to have a "backup" session discussing these issues at VSLive in
Orlando, and I submitted one for SF next year. May as well tell people
eventually. :-)

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/