VB6 vs VB.NET...Procedure Calling Syntax

[Patrick Troughton]

Dan Barclay <Dan@MVPs.org> wrote:
>On 12 Aug 2002 16:44:55 -0700, "Patrick Troughton"
><Patrick@Troughton.com> wrote:
>
>
>Right. In case you forgot, the issue you took up arms about was
>whether this syntax was called a "statement' or not.

That was your example, not mine. If you would have just admitted this in
the beginning instead of being so evasive, we would saved each other about
20 posts.

>Prior to VB.Net (from the time they were introduced to the language
>through VB6) they were consistent.

I haven't really thought about this. My point was to compare/contrast the
five procedure calling syntax rules (plus two special cases) of VB6 to the
VB.NET's single rule. But to address your point about consistancy, I'm not
sure that not having identical syntax for two different things (statements
and procedures) is such a bad thing. They're not the exact same things, why
should have the exact same syntax? In fact, could it not be argued that it
makes things a little more clear? Now, it's easier to tell the difference.
You could just look at the confusion in this thread alone to see that people
are having trouble telling the difference.

/Pat

[Patrick Troughton]

I already took the parens around statements idea to it's logical absurdity....

http://news.devx.com/cgi-bin/dnewswe...em=44649&utag=

I know I said this before, but just to be clear, let me say it again...I
do *not* think that requiring parens around all statements is a good idea.

/Pat

"Daniel Pratt" <dprREMOVETHISatt71@hotmail.com> wrote:
>
>
> I was wondering when you would take this to its illogical conclusion.
>
>Regards,
>Dan
>
>

[elliferg]

kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
>On Mon, 12 Aug 2002 17:35:33 -0500, Dan Barclay <Dan@MVPs.org> wrote:
>
>>Now, what do you think happens when you execute that Statement?
>>Surprise! It executes a procedure!
>
>Sorry, Dan, I don't this can be right. My information is that when a
>"Statement" is executed, certain members of congress conjugate in an
>anteroom off Bel-Aire Drive for coffee and muffins. There they speak
>about world problems and, if not too drunk on their own
>self-importance, come to conclusions which are then fed to a group of
>warlords in Outer Mongolia via fax. We all know the provision of
>horses there is really dire, and zebras, let alone donkeys, asses and
>mules don't really gallop in quite the same way. It's this problem
>which all "Statements" are endeavouring to fix - from the outside in,
>or, failing that, from the inside out. Meanwhile, said members of
>congress, now exhausted, are secretly returning to their desks and
>normal business is resumed within just a matter of minutes.
>
>Of course, I may be wrong about this, and statements could just be
>calling procedures, as you suggest. But such a bizarre suggestion is
>really difficult for some people to assimilate, which is why I thought
>of the alternative, much more sensible, "zebra" problem paradigm.
>
>MM

you forgot the omelettes.
elli

[Daniel Pratt]

"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3d58ff7e$1@10.1.10.29...
>
> I already took the parens around statements idea to it's logical
absurdity....
>
>
http://news.devx.com/cgi-bin/dnewswe....dotnet.discus
sion&item=44649&utag=
>
> I know I said this before, but just to be clear, let me say it again...I
> do *not* think that requiring parens around all statements is a good idea.
>
> /Pat

Neither do I. My problem with AddHandler specifically is that I can see
no significant semantic difference between it and any other method, built-in
or otherwise. Certainly the first time I saw AddHandler in use I thought it
was a method call and I was surprised not to see the parentheses.

Some people have suggested that VB.NET is a C++ programmer's perfect
vision of what VB should be. I, on the other hand, see a lot of VB6
influence on VB.NET that goes beyond the basic (pun intended) shared syntax.
Neither is afraid to hide a lot of "stuff" behind a keyword or two. Neither
is afraid to come up with arbitrary syntax for certain circumstances.

While such things can be good (programming languages are indended to
simplify, after all), in many cases I think I would like to be more aware
and more in control of what is going on. I do not want to pay the cost of
things I don't want or need. I would tolerate more cryptic syntax if it was
also more consistent, meaning that I had to keep less arbitrary rules in my
head. For these reasons I am favoring C# over VB.NET right now (a fact I
hate to admit in a VB.NET discussion group). This is all about balance, of
course. Some other languages put you in control of details that I can see no
great benefit to have control over (e.g. memory management), at least most
of the time.

Someday I'll design the perfect concept to machine code translater ;-)
It will neither hinder nor complicate. It will be consistent but not
cryptic. It will be easy but not arbitrary. In the mean time I'll be happy
to see things improving :-)

Regards,
Dan