> William Cleveland wrote:
> Andy Chevin wrote:
> >
> > Ignoring the backwards compatibility, runtime implications and

> > with C#, can anybody think of any areas where VB6 is better than VB.net?
> >

> DF would be nice, but I think I understand why they got rid of it, and
> it's worth it.

Actually, I've been having a bit of an eMail exchange with an MS employee,
who I won't name, and we touched on that subject. I do NOT understand why
they did away with DF _for VB_. The reasons stated for the lack of a
workable DF solution for the .Net platform *as a whole* were primarily
complications arising from the overhead of doing a good job of refcounting
in a free/multi-threaded environment. OK, that's fine as far as it goes.

However, I think they stopped thinking about the problem too soon because
they were looking at the wrong perspective.

In VB6 we did not have free-threading, and how much code was really written
that took advantage of spawning multiple threads within the
apartment-threading architecture that was made possible, but certainly not
simple, in VB6? By %-age, I wager that is a very small number of the total
VB6 code/codebase in place in business, although I am very willing to be
shown I am wrong in thinking that way.

If my assertion/assumption is anywhere near correct <and I'll grant that may
be a very big IF>, then, as is the case for the property set/get question,
VB.net lost VB6 functionality due to factors that were not directly related
to carying it's current functionality and user codebases foreward.
Anotherwords, if much/most of the VB6 code that could/would have been
version-upgraded would not have run afoul of threading issues which would
have caused DF refcounting problems in .Net, this codebase lost the DF
functionality for no net<or, .Net> gain.

Suppose it were possible to have the VB.Net compiler enforce a rule to the
effect that DF - or a pseudo-DF & refcounting capability (and your current
codebase's _Terminate events) operate - even at a performance cost, so long
as the application used only one execution thread? Would that easier
foreward-migration be worth the execution speed trade-off? I would think so.

I attempted, many moons ago in the vb.vb7 newsgroup, to put a suggestion
forward that could, possibly, have made that DF/pseudo-DF/refcounting
semantic model possible to do (IMO, at least). At that time, I proffered
that suggestion as a framework-wide solution, but if cast in this light, as
VB-only single-threaded app possibility instead, I think it really would be
a viable alternative for a large chunk of VB6 code moving forward...with all
the benefits of easier foreward code-migration.

Another comment that relates to this question - by direct extension - is
that, in conversation with this MS person, it was thought that the many
VB.Net "gratuitous incompatibilities" arose out of the "well, because of
this DF thing we have to break the 100% backwards compatibility rule for VB,
here"-thinking led to a dam-break of pent-up "urge to change things" <for
whatever reason> and the raft of "gratuitous incompatibilities".

If this alternate solution were to make a pseudo-DF capability _*possible*_
<note I mean "possible", not likely/unlikely etc.,.> for VB.Net, then, the
originating impetus for that dam-break of "gratuitous",
backwards-compatibilty-compromising changes is lost...perhaps there might
then be an impetus for MS to provide a "OPTION VB6Compatible"/"OPTION
NETCompatible" syntax evaluation switch...?