They created J#, why couldn't they do VB#?

[Mike Mitchell]

On Mon, 26 Nov 2001 11:00:48 -0800, "Jonathan Allen"
<greywolf@cts.com> wrote:

>Please pick a different example, as there is nothing wrong with global
>functions. It would suck if we had to use a class every time we wanted a
>simple math function.

Isn't that what OOP purists strive for, though? How could that 'simple
math function' serve as a base class for inheriting some extra
functionality to serve the software reuse God if all it was was a
function?

MM

[Mike Mitchell]

On Mon, 26 Nov 2001 11:02:47 -0800, "Jonathan Allen"
<greywolf@cts.com> wrote:

>They are just names, they have no meaning on there own. Calling it VB#
>instead of VB.Net would not change it one bit.

No, but calling it B# and allowing classic VB to continue ad infinitum
as a parallel product would change a lot.

No posts from me for a start.

MM

[Jonathan Allen]

> But what I was really refering to was that many VB programmers I've worked
> with want EVERYTHING global. They refuse to use classes, and instead use
> a module that includes a struct and all the functions that act on that
struct.
> I'm not a big fan of this.

Oh, I agree with you there. It is just that in my experience, too many
people think that globals are inherently evil. They believe OO is a religion
and everything has to be a class, even when it is totally inappropriate.

As for your specific example, I hope to see a lot less of that happening now
that structs can have methods.

--
Jonathan Allen



"Ian Drake" <ian@dotnetnut.com> wrote in message
news:3c02a0ee@147.208.176.211...
>
> Jonathan
>
> >> god forbid they have to stop writing global functions
> >> in modules.
> >
> >Please pick a different example, as there is nothing wrong with global
> >functions. It would suck if we had to use a class every time we wanted a
> >simple math function.
> >
> As Zane pointed out, one could use static functions as a replacement,
while
> also gaining the benifit of clasification of the fnction. Such as a Math
> class containing math functions, etc...
>
> But what I was really refering to was that many VB programmers I've worked
> with want EVERYTHING global. They refuse to use classes, and instead use
> a module that includes a struct and all the functions that act on that
struct.
> I'm not a big fan of this.
>
> Ian

[Ian R]

According to you.

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:3c02bd0d.9746977@news.devx.com...
>
> No. No time is necessary. The very second they decided to dump classic
> VB, it was the wrong decision.
>
> MM

[Mike Mitchell]

On 26 Nov 2001 21:29:17 GMT, "Rob Teixeira" <RobTeixeira@@msn.com>
wrote:

>Public static class methods ARE global functions.

Er, "Public static class methods" kind of smells like OOP, if you ask
me. The very instant you wrote that word "class", you lost a few
hundred thousand classic VB developers - whoosh! Like brain cells
dying after drinking too much, also bad for one's health.

MM

[Ian R]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:3c02c126.10796037@news.devx.com...
>
> No, but calling it B# and allowing classic VB to continue ad infinitum
> as a parallel product would change a lot.
>

You can use classic VB for as long as you want. Nobody (except you
apparently) is stopping you.

> No posts from me for a start.
>

I'm sure you'd find some other thing to ***** about.

> MM

[Thomas Eyde]

> Could u please enlighten us, how VB.Net lacks greatness of VB Classic

VB Classic shields us from the inner workings (except default properties and
collection enumerations), in .Net that is not true.

Do you really enjoy the enforcement of the new keywords related to OO?
- I have to specify which methods to override. Of course I want to override,
that's the strength of OO, isn't it?
- When to use Overloads? VB.Net enforce different coding styles based on
scope.
- Beta2 gives rather stupid suggestions when Overrides is missing, thinking
you really want Overloads.
- The combination of Overrides Overloads looks stupid, you can't have one
without another.
- When do we really need Shadows? Do we need it so much to defend its
defaultness?
- 0-based arrays!?
- Why the MustInherit? What's wrong with Virtual, everyone else is using it?
- If the WinForm generated code is not meant for editing, why is it visible?

> (or I have to call u - MM2 the FUD).

I don't know what that means.

/Thomas

[Thomas Eyde]

> They did. But they called it VB.NET instead.

I don't think they did. There is a rumour about VB7 that was ditched in
favour of VB.Net

/Thomas

[Thomas Eyde]

> Please look into what makes a language .NET compatible, with this
knowledge
> you might see that it is not as simple as making a VB#. If you map
existing
> language functionality to .NET functionality then you would see that Java
> maps easily to .NET and VB doesn't. Because of this, VB needs new OO
keywords
> to extend its OO abilities.

J# conforms to JDK 1.1.4 (I believe, not that into Java). No new keywords
there as in VB.Net. So MS pleases strangers, but ignores the relatives?

I can't see how VB.Net is meant to have a future. It's designed to attract
supporters it does not have and drive away the ones it could have.

/Thomas

[Jonathan Allen]

> Do you really enjoy the enforcement of the new keywords related to OO?

As it stands, no.

> - When to use Overloads? VB.Net enforce different coding styles based on
> scope.

The idea behind that is you need Overloads to say that you acknowledge the
existence of other overloads in a base class. You do not need it to overload
functions declared locally since you can see them in the class file.

I think it was a bad idea. It should have been all or nothing. And if the
decision is 'all', then the IDE should insert or remove it automatically.

> - The combination of Overrides Overloads looks stupid, you can't have one
> without another.

Overloads should have nothing to do with Overrides.

> - When do we really need Shadows?

It is used when dealing with versioning issues. If the Base class later adds
a method that has the same name as one your subclass, you can use Shadows to
keep it from breaking everything. Shadows should never be part of the
class's original design.

> Do we need it so much to defend its
> defaultness?

NO!

> - Why the MustInherit? What's wrong with Virtual, everyone else is using
it?

We do not use Virtual because the term has no intrinsic meaning. Keywords
whose English definition differs from its programming definition are harder
to learn and remember.

For example, Abstract, not Virtual, means MustInherit. I have lost track of
how many times people got that wrong.

Consider the keyword "static". In English, it basically means unchanging or
constant. So the logical equivalent in VB is Const. However, C# uses static
to mean something that is shared between instances of a class. A "static"
property is simply not static.

> - If the WinForm generated code is not meant for editing, why is it
visible?

It is hidden in a region. There may be times when you want to alter it. For
instance, when control load order is important.

--
Jonathan Allen



"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3c033d3f@147.208.176.211...
> > Could u please enlighten us, how VB.Net lacks greatness of VB Classic
>
> VB Classic shields us from the inner workings (except default properties
and
> collection enumerations), in .Net that is not true.
>
> Do you really enjoy the enforcement of the new keywords related to OO?
> - I have to specify which methods to override. Of course I want to
override,
> that's the strength of OO, isn't it?
> - When to use Overloads? VB.Net enforce different coding styles based on
> scope.
> - Beta2 gives rather stupid suggestions when Overrides is missing,
thinking
> you really want Overloads.
> - The combination of Overrides Overloads looks stupid, you can't have one
> without another.
> - When do we really need Shadows? Do we need it so much to defend its
> defaultness?
> - 0-based arrays!?
> - Why the MustInherit? What's wrong with Virtual, everyone else is using
it?
> - If the WinForm generated code is not meant for editing, why is it
visible?
>
> > (or I have to call u - MM2 the FUD).
>
> I don't know what that means.
>
> /Thomas
>
>

[Jonathan Allen]

> J# conforms to JDK 1.1.4 (I believe, not that into Java). No new keywords
> there as in VB.Net. So MS pleases strangers, but ignores the relatives?

J# is a migration language, it is not meant to be a long term solution. It
lacks important CLR features such as properties. It is also slower than C#,
as it has to run on top of an abstraction layer that simulates the Java
framework.

--
Jonathan Allen



"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3c034a5e@147.208.176.211...
> > Please look into what makes a language .NET compatible, with this
> knowledge
> > you might see that it is not as simple as making a VB#. If you map
> existing
> > language functionality to .NET functionality then you would see that
Java
> > maps easily to .NET and VB doesn't. Because of this, VB needs new OO
> keywords
> > to extend its OO abilities.
>
> J# conforms to JDK 1.1.4 (I believe, not that into Java). No new keywords
> there as in VB.Net. So MS pleases strangers, but ignores the relatives?
>
> I can't see how VB.Net is meant to have a future. It's designed to attract
> supporters it does not have and drive away the ones it could have.
>
> /Thomas
>
>

[Patrick Troughton]

"Thomas Eyde" <thomas.eyde@online.no> wrote:
>I can't see how VB.Net is meant to have a future.

This is one of the Great Myths of the Anti-.NET Religion. The fact is that
VB.NET is *already* very successful - many companies and individuals are
already using it.

/Pat

[Rob Teixeira]

You totally missed the point (and cut the relevent part of the post).
Internally the two are the same both semantically and, in vb.net, in implementation.
The point is that you can still write global functions in a module.

And rather than loosing a few hundred thousand classic VB programmers simply
due to the word "class" (which you DON'T need to use, btw), I believe it's
the lack of OO which *has already* driven hundreds of thousands of classic
VB programmers to other languages.

-Rob

kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
>On 26 Nov 2001 21:29:17 GMT, "Rob Teixeira" <RobTeixeira@@msn.com>
>wrote:
>
>>Public static class methods ARE global functions.
>
>Er, "Public static class methods" kind of smells like OOP, if you ask
>me. The very instant you wrote that word "class", you lost a few
>hundred thousand classic VB developers - whoosh! Like brain cells
>dying after drinking too much, also bad for one's health.
>
>MM

[Rob Teixeira]

"Thomas Eyde" <thomas.eyde@online.no> wrote:
>
>> Overloads should have nothing to do with Overrides.
>
>Agree, but when you are overloading a member of the base class, aren't you
>also overriding it?

Not entirely. A method is unique to its signature. So DoStuff() is not really
the same function as DoStuff(ByVal ToObject As Object). If you overload,
you are in fact adding a new member over the interface provided by the base
class, and are not hiding the base class' behavior, which is what Overrides
is supposed to do.

>> > - When do we really need Shadows?
>>
>> It is used when dealing with versioning issues. If the Base class later
>adds
>> a method that has the same name as one your subclass, you can use Shadows
>to
>> keep it from breaking everything. Shadows should never be part of the
>> class's original design.
>
>That I don't understand. Why can't the subclass then override it?

Only virtual (Overridable) functions can be overridden. Non-virtual functions
don't work on the V-Table principle. The only way to hide a non-virtual base
class function is to shadow it.

>> Consider the keyword "static". In English, it basically means unchanging
>or
>> constant. So the logical equivalent in VB is Const. However, C# uses
>static
>> to mean something that is shared between instances of a class. A "static"
>> property is simply not static.
>
>That's not good either. Why invent new terms or give them non intuitive
>meaning?

Well, not only would the logical VB equivalent be Const, but VB's traditional
usage of the Static keyword already meant an implementation of a local variable
that's not placed on the stack, which is a whole other animal to begin with.

While some of the new OO keywords are a bit different and sometimes verbose,
I think they make sense for the most part. It's stuff like AndAlso that i
have a problem with...

-Rob

[Thomas Eyde]

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3c0356a1@147.208.176.211...
> > - The combination of Overrides Overloads looks stupid, you can't have
one
> > without another.
>
> Overloads should have nothing to do with Overrides.

Agree, but when you are overloading a member of the base class, aren't you
also overriding it?

> > - When do we really need Shadows?
>
> It is used when dealing with versioning issues. If the Base class later
adds
> a method that has the same name as one your subclass, you can use Shadows
to
> keep it from breaking everything. Shadows should never be part of the
> class's original design.

That I don't understand. Why can't the subclass then override it?

> For example, Abstract, not Virtual, means MustInherit. I have lost track
of
> how many times people got that wrong.

I made it wrong. Sorry.

> Consider the keyword "static". In English, it basically means unchanging
or
> constant. So the logical equivalent in VB is Const. However, C# uses
static
> to mean something that is shared between instances of a class. A "static"
> property is simply not static.

That's not good either. Why invent new terms or give them non intuitive
meaning?

/Thomas