Re: VB6, VB2005, or Something Else?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
news:eLa9wk5XGHA.4920@xxxxxxxxxxxxxxxxxxxxxxx
Ralph wrote:
"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
news:eg1VB6yXGHA.1348@xxxxxxxxxxxxxxxxxxxxxxx
Regarding "only" VB I agree - would be possible.

Andre

"Yes, but that would restrict the C++ applications and other languages
using
the COM objects to the old model."

Huh?

That is pure nonsense. Actually this whole thing about some kind of
'object
model restriction' is also nonsense. VC++ is able to produce code that
will
run in a 'managed' or 'unmanaged' environment. VB (the real VB) could
have

The discussion was about extending the current COM object model with
overloading and polymorphism. I only stated that this enhancement would
be the same as .NET object model - incompatible and not usable directly
from older languages, besides through wrappers e.g. COM interop.

Surely the VB object model could have been enhanced and could have been
compiled to both - native and managed. But you cannot expect it to be
COM compatible anymore. Even if you are compiling to native code.
All in all I only had the odd feeling that enhancement of the current
object model wouldn't be a good idea, to answer this question I would
have be more experienced with VB6, which I'm unfortunately not.
Though it could have been supported in both worlds. Managed and native.
Which would be the same as in C++ -> not the same but both are supported.

the same ability. More importantly VC++ is able to produce hybrids which
run
within both worlds - VB could have have the ability to do the same.

Yes. Either it compiles to native or managed code. But this only applies
to C++ code. If you are using managed code (C++/CLI) you cannot compile
your application to native code anymore - no way.

VC++ does it the same way as VB could have done it. Through that great
miracle of the programmer's arsenal - "yet another layer of
indirection".

I have stated this too. VB could have supported a compatible mixed mode
compilation. But this would have lead to a slower adoption of .NET and
would have needed more developer resources. Most here would state
otherwise. But if I have a look at Delphi I think it would have been
that way.

Or look at it this way. VC++ right now is able to produce managed code -
yet
its ability to work with the "old COM model" doesn't appear to be
adversely
affected.

Yes. But you cannot use directly C++ from other languages and you cannot
use directly .NET objects from COM objects (in other languages) and mix
them freely. You have certain restrictions, which VB would have too.

The whole idea that VB is or was somehow inherently locked out of the
dotnet
world - is just plain silly. MS just didn't want to do it.
-ralph

Andre

I shouldn't have butted in. As you all are having having great fun and I
have no desire to go into detail to defend what "might have been".

I just think your argument is totally specious from top to bottom.

I don't think any of the gurus was serious suggesting that changing the COM
specification is a prerequisite to accommodate a new VB., nor do I think
anyone was suggesting that code written for a managed environment should be
'backward compatible'.

While the analogy is imperfect, it is similar to DAO & ADO. They accomplish
almost identical tasks - yet the internal details are very different.

Do you think it would be all that difficult to create an ADO.Net for VB? Pop
in a managed provider, an adaptor thingy, a couple of controls to accept
xml, and bang! - you got ADO.Net a la VB. Is it a requirement that the code
would be identical? Did ADO have to 'look' like DAO? Does ADO code have to
be backward compatable?

Currently VB is using OLE services to manage objects. It used to use DDE. VB
could have easily offered managed objects using managed services. What
really changed in a TextBox's behavior when they became based on OLE? (ie,
the difference between a TextBox in VB3 and one in VB6) - Oh, oh, I know -
VB6 TextBoxes also support DDE. It is called indirection and enhancement -
programmers write that stuff all the time.

Or take implemention inheritance. What magic does C++ do here. The compiler
simply takes the various class directives, applies some rules, and creates
at runtime a single object which combine elements of several classes - do
you really believe - and want to tell the world that this couldn't have been
done in VB without 're-writing' the COM specification. <?>

As a sidnote, what is really funny to me, is if VB6, back in '98, had
implemented implementation inheritance, but added the same restrictions
dotnet imposes, there would have been such a hue and cry - "VB is still not
a true OOPL". <G>

-ralph






.

Relevant Pages