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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 20 FirstFirst 123412 ... LastLast
Results 16 to 30 of 291

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

  1. #16
    Mike Mitchell Guest

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

    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

  2. #17
    Mike Mitchell Guest

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

    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

  3. #18
    Jonathan Allen Guest

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

    > 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



  4. #19
    Ian R Guest

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

    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




  5. #20
    Mike Mitchell Guest

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

    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

  6. #21
    Ian R Guest

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


    "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




  7. #22
    Thomas Eyde Guest

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

    > 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



  8. #23
    Thomas Eyde Guest

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

    > 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




  9. #24
    Thomas Eyde Guest

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

    > 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



  10. #25
    Jonathan Allen Guest

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

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



  11. #26
    Jonathan Allen Guest

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

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



  12. #27
    Patrick Troughton Guest

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


    "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

  13. #28
    Rob Teixeira Guest

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



    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



  14. #29
    Rob Teixeira Guest

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


    "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

  15. #30
    Thomas Eyde Guest

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


    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center