Author Topic: VB versus C#  (Read 4744 times)

0 Members and 1 Guest are viewing this topic.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
VB versus C#
« on: August 27, 2006, 02:08:22 PM »
(VS 2005)

Not, not the standard debate. I'm curious about MS's decision to keep the legacy Module paradigm when Shared Methods et al in Classes achieve the same AND is more aligned with C#'s philosophy.

Eh? Ok, a pinch of minimalist code to illuminate.

C# --

Code: [Select]
using System;

namespace CadLabs {

    class Crud {
        public string ReturnsSomeString()
        {
            return "Hello yada.";
        }
    }

    class ConsApp {
        static void Main (string[] args) {
            Crud crud = new Crud();
            Console.WriteLine(crud.ReturnsSomeString());
            Console.ReadKey();
        }
    }
}

Equivalent VB code (hand rolled) --

Code: [Select]
imports system

namespace CadLabs

    class Crud
        public function ReturnsSomeString() as string
            return "Hello yada"
        end function
    end class

    class ConsApp
        shared sub Main (args() as String)           
            dim crd as new Crud()
            Console.WriteLine(crd.ReturnsSomeString())
            Console.ReadKey()
        end sub
    end class

end namespace

Works fine and is loosely 1:1 with C#.

But if you create a console app using the VB wizard <cough> you'd end up with this kind of code crap --

Code: [Select]
imports system

namespace CadLabs

    class Crud
        public function ReturnsSomeString() as string
            return "Hello yada"
        end function
    end class

    module ConsApp '' ackkk
        sub Main (args() as String)
            dim crd as new Crud()
            Console.WriteLine(crd.ReturnsSomeString())
            Console.ReadKey()
        End Sub
    end module

end namespace

Why bother with Modules? Everything you might place in a Module can be put into a Class as Shared Functions, Procedures, Constants (Constants are implicitly shared) ad nauseum.

While you can't define the Class as Static as you can in C# you can prevent instantiation via a private constructor etc. (like C# IIRC) --

Code: [Select]
namespace CadLabs

    class StaticClass

        private sub New()
            ''  prevents instantiation
        end sub
       
        public const THEASWER as Integer = 42
       
        shared sub DoSomething ()
            for nop as integer = 0 to 42
                ''  whistle
            next nop
        end sub
       
        shared function ReturnSomething() as string
            return "Doh!"
        end function
       
    end class

    class ConsApp
        shared sub Main (args() as String)           
            if StaticClass.THEASWER = 42 then               
                StaticClass.DoSomething()
                Console.WriteLine(StaticClass.ReturnSomething())
                Console.ReadKey()
            end if
        end sub
    end class

end namespace

Why not adhere as close as possible to C# convensions especially since one may prototype in VB, later porting (portions) over to C#?

Am I missing something? Are there compelling reasons for using Modules instead of Classes or it just legacyitus? Anyone using VB 2005? Tried it? Don't care?

Note both Visual BASIC 2005 Express and SharpDevelop 2.0 generate the Module code, I don't know about other versions of Visual Studio but it's a logical assumption.

rant|spew|froth|blink
« Last Edit: August 27, 2006, 02:52:40 PM by MP »
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: VB versus C#
« Reply #1 on: August 27, 2006, 06:28:09 PM »
I think it is just legacyitus, I guess the old vb used modules simply to seperate code sections which would be similar to using different files for different types of classes.
Classes in old VB from what I've seen are a more specialised item and are not used near as much as with C#/++ as VB wasn't really OO in its pure sense so modules I guess were the next best thing.
It does seem like MS are trying to swing VB users around to the OO way of thinking and you do see quite a lot more classes in the new .net version. I haven't had a close look but they may enforce full OO it already(?)
It makes sense I guess as it would be a lot easier to compile similar OO code from different languages than it would if you had to compile both OO and non OO app's to IL.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: VB versus C#
« Reply #2 on: August 27, 2006, 07:08:44 PM »
.. AND, to make it more confusing, there is a Module Class, usable by both Vb and C#.

I have had a long term hatred of VB/A, the word Dim alone causes a brain freeze < for me >, so thankfully, I wont be prototyping in VB :lol>:

... but I do understand your quandry MP


kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: VB versus C#
« Reply #3 on: August 27, 2006, 07:36:22 PM »
I've also noticed in .net2 that you can split classes over any number of files (or is that what you are talking about Kerry?). IMO, if a class is that big you probably need to break it down to another class or more. Classes should be like functions in that they perform very simple/single operations to aid in the maintain-ablility and intention of the code.
Namespaces are a good concept over many files but classes...??
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: VB versus C#
« Reply #4 on: August 27, 2006, 08:01:58 PM »
Split classes wasn't what I meant .. that is great when dealing with forms and form controls .. ideal for separating the 'wizzard' code from the manual ..

I meant this one ..
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemreflectionmoduleclasstopic.asp
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: VB versus C#
« Reply #5 on: August 27, 2006, 08:25:53 PM »
gotcha.

Yes, forms are a different animal when it comes to class sizes, but still, you should be able to seperate your working code away from the form event handlers to keep the form files compact and easy to maintain.
It is easy while doing concept work though to put all of your implementation into the event handler, whether it makes it to a new class method or not ....?? :D
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: VB versus C#
« Reply #6 on: August 28, 2006, 06:59:00 AM »
Forgive me, I just woke up and won't have time later, so I gotta take a stab at this now <yawn>.

I think it is just legacyitus, I guess the old vb used modules simply to seperate code sections which would be similar to using different files for different types of classes.

I think it's a combination of legacyitus and "convenience" -- it's less work to create a module, you don't have to tell the module it cannot be instantiated (implicit) nor explicity tell each method etc "You are shared" (vb's equiv to static) because that's also implicit. I say "convenience" because if down the road one wanted to port module based code to C# they'd have to rewrite it unless there's some <eeek> VB->C# wizard app <I'll pass>.

Classes in old VB from what I've seen are a more specialised item and are not used near as much as with C#/++ as VB wasn't really OO in its pure sense so modules I guess were the next best thing.

VB was never truly OO, more like OO lite, but I wouldn't say "modules were the next best thing". Speaking of old VB (< ver 7) Modules were where you placed common, non OO code, like what you'd find in static C# (helper) classes. Can't speak for anyone else but having coded in VB since the early 90s I wrote a lot of VB code that was as OO as it would allow (VB has had classes since Version 4 IIRC).

It does seem like MS are trying to swing VB users around to the OO way of thinking and you do see quite a lot more classes in the new .net version. I haven't had a close look but they may enforce full OO it already(?)
It makes sense I guess as it would be a lot easier to compile similar OO code from different languages than it would if you had to compile both OO and non OO app's to IL.

Yep, insert laughter here if you must, but VB is now truly OO, including inheritance, generics ... yada. An aside, it now supports all the unsigned suite of integers ('bout freakin' time), arrays are zero based (yeha) ... yada. In a nutshell it has moved a lot closer to C#.

One thing I'm trying is to code without using the Microsoft.VisualBASIC libraries, instead just using the BCL like a C# coder would be forced to (not C# envy at all, just trying to minimize porting activities down the road).

So instead of (traditional VB via Microsoft.VisualBASIC.Information) --

for i as integer = 0 to ubound(anArray)
    ...
next i


Going BCL is --

for i as integer = 0 to anArray.GetUpperBound(index)
    ...
next i


Etc. I could write pages noting the differences but I've not the time.

.. AND, to make it more confusing, there is a Module Class, usable by both Vb and C#.

Meh.

I have had a long term hatred of VB/A, the word Dim alone causes a brain freeze < for me >, so thankfully, I wont be prototyping in VB :lol>:

Ahhh, my dilemna too, but the other way 'round. I've taken numerous runs at C#. While I appreciate it academically when it comes to writing any code in it I just get nautious, it just looks aweful to me (I'm not saying VB is pretty, just familiar). Still, I have numerous books on C# (the BCL, The C# language, Forms) to augment my one VB book (that's another story).

... but I do understand your quandry MP

Thank you sir.

<dang out of time>
« Last Edit: August 28, 2006, 07:11:52 AM by MP »
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst