VBScript functions versus VB functions

  • Thread starter Thread starter Herfried K. Wagner [MVP]
  • Start date Start date
Herfried,
Maybe I had to add the word "too",Maybe you underestimate the programmers from Microsoft,
I don't. So I don't think that they did not do that too, it's so much
easier for the framework you know?
What did the Microsofties do? I don't really understand the meaning of the
sentence above...

Making the same intermidiate code for Mid(xxxxxxxx) and a.substring(xxxx).

Cor
 
Herfried K. Wagner said:
Hello,



No. VB.NET is _not_ an OO language. VB.NET _supports_ OOP as a _tool_.
You can still write applications in VB.NET without using OOP (module, 'Sub
Main', ...). C# _is_ a programming language limited to OOP only.

Uh, yes VB.NET is absolutely an OO language. You can certainly write code
that bypasses classes, but that is not one of the criteria for an OO
language.
No. The old functions _are_ methods. 'Right', for example, is a method of
the 'Strings' class.

Correct. and Right(string) is the old VB 6.0 function that string.Right()
replaces. Right(string) is the "old" function I am refering to. If you
were to use Right(string), all that would happen is a call to the string's
..right() method (which is an extra processing step) - why have your code
take an unecessary step?
No. They are main part of the Visual Basic .NET programming language.

No, the methods that have replaced the functions are a main part of VB.NET.
The functions are a "crutch". I believe they are provided in the
VBCompatibilty assembly. They are for migration of code/developers.

If
you don't use them, you may want to turn to C#. I don't know any C#
programmer who won't use certain features of his language only because they
don't fit in a certain programming paradigm.


VB.NET is a programming language for developing VB.NET solutions.


The Framework is good, but VB.NET provides _more_.

I think you've got that one backwards. All the language does (any language)
is provide access to the .NET Framework. The engine behind any .NET
application is the framework, not the language. Sure the language can make
using the Framework eaiser or more efficient and the language is not to be
discounted. But the Framework is where it all happens. That's why all .NET
languages compile to IL first and native code second. The CLR, Garbage
Collection, Security, ADO.NET, WinForms, ASP.NET, Base Class libraries,
etc., etc. are all part of the Framework, not the language.
 
Hello,

Scott M. said:
Old = Legacy = Non-consitent with current techniques

I don't think so. The VB.NET functions like 'Right', 'Mid', and
'AppActivate' are methods of classes, they are not simple functions any more
(in VB Classic they were members of modules). As mentioned before,
sometimes there isn't even a "replacement" (I hate the word in this context)
for the "function" available in the Framework.
Not OOP <> Bad

Not OOP = Not OOP [.NET is ALL about OOP & the
changes to VB.NET reflect that]

I don't agree... OOP is nice, but OOP only is IMO _bad_ because it doesn't
reduce complexity of simple tasks.
 
Hello,

Scott M. said:
Uh, yes VB.NET is absolutely an OO language.

Sorry, I missed out the most important word in my sentence. It should read
"VB.NET is _not_ an OO-only language."
Correct. and Right(string) is the old VB 6.0 function that
string.Right() replaces. Right(string) is the "old" function I
am refering to. If you were to use Right(string), all that would
happen is a call to the string's .right() method (which is an extra
processing step)

There is no 'String.Right' method. That's the problem. If there was a
'String.Right' instance method, I would not use 'Strings.Right' any more
because it doesn't have any advantages over the instance method. But at the
moment there is no replacement for the 'Right' function available (OK,
'Substring' exists, but 'Right', and 'Left' make understanding code easier
to the reader).
- why have your code take an unecessary step?

See above. I don't want to say that all of the methods in the VB Runtime
Libarary should be used, I only want to point out that in some cases the VB
Runtime Libarary extends the Framework by uinique methods.
programming language.

No, the methods that have replaced the functions are a main
part of VB.NET.

They are main part of .NET. VB.NET provides some "shortcuts" that fit
better into the BASIC programming paradigm.
The functions are a "crutch". I believe they are provided in the
VBCompatibilty assembly. They are for migration of code/
developers.

The functions I am talking about are implemented in the Microsoft Visual
Basic .NET Runtime Libarary. That's not the Compatibility Libarary which
provides some VB6 controls and functionality.
I think you've got that one backwards. All the language does
(any language) is provide access to the .NET Framework.
The engine behind any .NET application is the framework,
not the language.
ACK

Sure the language can make using the Framework eaiser

110% ACK -- that's the only reason why more than one programming language
for .NET exists.
or more efficient and the language is not to be
discounted. But the Framework is where it all happens.
That's why all .NET languages compile to IL first and native
code second. The CLR, Garbage Collection, Security,
ADO.NET, WinForms, ASP.NET, Base Class libraries,
etc., etc. are all part of the Framework, not the language.

ACK -- but why not extend the framework by a libarary providing functions
that fit better into the programming scheme of a certain programming
language?
 
Well,

Is it a big problem to let me know about some help/tutorial of asp.net
locations ?
I don't see this a big deal (I have already looked in google, but I didn't
find one - maybe I missed something,
but please, please if you can reffer me to some help).

Besides - about the other newsgroup, is
microsoft.public.dotnet.framework.aspnet is fine ?

Thanks :)
 
Herfried K. Wagner said:
Hello,



I don't think so. The VB.NET functions like 'Right', 'Mid', and
'AppActivate' are methods of classes, they are not simple functions any
more

When called like Right(string), you are using it as a simple function. This
is my point. By calling the Right() method of a string, you are using the
string object's method directly. When using Right(string) as a function you
are adding an extra step to get to that string's Right() method.
(in VB Classic they were members of modules). As mentioned before,
sometimes there isn't even a "replacement" (I hate the word in this context)
for the "function" available in the Framework.

You're right again! But, where replacements do exist, they should be used.
Not OOP <> Bad

Not OOP = Not OOP [.NET is ALL about OOP & the
changes to VB.NET reflect that]

I don't agree... OOP is nice, but OOP only is IMO _bad_ because it doesn't
reduce complexity of simple tasks.

OOP is a "concept" or a "paradigm" if you like. In general, when you have
to mix concepts or paradigms in one solution, things get confusing. Now,
let me be clear, I'm not standing on a soap box here claiming that it's got
to be OO or not at all. I'm simply saying that in .NET (with respect to
these legacy VB 6.0 functions), there really isn't a strong case to be made
for their use over the new OOP method calls.
 
Herfried,
I would not take to much time on this, the messages from Scott shows that he
does not understand it all.
But to you.
See above. I don't want to say that all of the methods in the VB Runtime
Libarary should be used, I only want to point out that in some cases the VB
Runtime Libarary extends the Framework by uinique methods.

Are you sure of this (and this is to the meaning of my post in the other
thread about intermidiate code) I don't see a runtimer that extends the
framework when I build an exe when I use Microsoft.Visuals.Basic things.

This has given me the idea that the code build with the
Microsoft.Visual.Basic classes and the code with the System.net classes
makes the same software. And because of the fact that it is intermidiate
software gives the same processing results.

(That had probably not been so when it all was end code).

Do you know something about this?

Cor
 
Hello,

Scott M. said:
When called like Right(string), you are using it as
a simple function. This is my point. By calling the
Right() method of a string, you are using the string
object's method directly.

I would call the 'Right' method of the string too, if it would exist.
You're right again! But, where replacements do exist,
they should be used.

There exist replacements in VB.NET which can be used.
OOP is a "concept" or a "paradigm" if you like. In general,
when you have to mix concepts or paradigms in one solution,
things get confusing. Now, let me be clear, I'm not standing
on a soap box here claiming that it's got to be OO or not at all.
I'm simply saying that in .NET (with respect to these legacy
VB 6.0 functions), there really isn't a strong case to be made
for their use over the new OOP method calls.

I agree with you and I would like it if they would add functions like 'Left'
and 'Right' to the 'String' class.
 
Hello,

Cor said:
I would not take to much time on this, the messages from Scott
shows that he does not understand it all.
;-)


Are you sure of this (and this is to the meaning of my
post in the other thread about intermidiate code) I don't see
a runtimer that extends the framework when I build an exe when
I use Microsoft.Visuals.Basic things.

For example, the 'AppActivate' method doesn't have a replacement in the
framework.
This has given me the idea that the code build with the
Microsoft.Visual.Basic classes and the code with the
System.net classes makes the same software. And because
of the fact that it is intermidiate software gives the same
processing results.

Yes.
 
No Cor, I just don't understand YOUR post at all. And by understand, I
don't mean from a VB.NET standpoint. I mean from a reading of the English
language standpoint.

I've read many of your posts on several topics and very often people will
reply to you that they can't understand what you are saying because your
English and writing skills aren't sufficient to express your point.
 
Hello,

Scott M. said:
No Cor, I just don't understand YOUR post at all. And by
understand, I don't mean from a VB.NET standpoint. I
mean from a reading of the English language standpoint.

Cor and some other people here are not native English speakers. Even if
their postings (including mine) are hard to understand, most of them can be
understood by the reader.

;-)
 
Jak bedziesz wladal wiesza ilosia jezyków bedzie to dla ciebie nie
najwazniejsze bo chodzi tu o resultat a nie metode.
 
Mr. x.
I told you yesterday that the most people who are actibe in this group are
specialized in the VB.language and that they use Visual.Studio.Net or
VB.studio.Net.

Yesterday Herfried told me, that that was not important. He and a lot of
others did try to help you as much as possible to day.

We don't know if there is a *.chm file. I myself have looked for the .Net
framework SDK if there was a *.chm file with it, but I doubt it. Writting
this maybe you are intrested in the Script language from Microsoft. In that
is I thought a *.chm with examples of JavaScript and Visual.Basic script.

I have looked it up for you.
It is at
http://www.microsoft.com/downloads/...familyid=0a8a18f6-249c-4a72-bfcf-fc6af26dc390

Remember the people who answered you are no paid people.
The took time to help you on there free saterday in there country too.

Cor
 
I am not native English speeker too, but on every post of yours, you don't
get to the point - Is there a file (a true file, indeed, not tutorial) of
Visual VB help (like *.chm) ?

Thanks :)
 
Hmmm.
Very interesting.
Kidding - I don't understand your language, and even if it is a curse or
something - I don't mind.

BTW, see my post for my time problem, I think you interesting to know, and I
think it is a Bingo.
posted at : "Tutorials for VB'.

Cheers...
 
Thanks :)

I'll manage somehow...

See my post on "Tutorial for VB" - it has an answer for my time problem, and
I think it is a Bingo...
Please inform me at "Tutorial for VB" subject.

Thanks :)
 
Back
Top