Re: VB6, VB2005, or Something Else?

On Wed, 12 Apr 2006 07:50:16 +0200, Andre Kaufmann
<andre.kaufmann.bei@xxxxxxxxxxx> wrote:

Michael B. Johnson wrote:
On Tue, 11 Apr 2006 13:12:31 -0500, Paul Clement
<UseAdddressAtEndofMessage@xxxxxxxxxxxxxx> wrote:
[...]
object oriented. You mean to say they *couldn't* have implemented polymorphism
in the existing language? Why not?

Procedure Overloading? Why not?

They could have done this. But this would have IMHO broken compatibility
with older VB code too. COM doesn't support all that features.

You don't think name mangling could have been implemented in the back end
runtime linker/interpreter/CLR, similar to C++? I'm not so sure you understand
how compilers work. You don't think that name mangled procedures could have been
exposed via COM?

Or if necessary, you don't think that backwards compatibility could have been
maintained and .NET made accessible to old code?

I respectfully disagree.

I don't understand the object model in VB6 very well. Obviously a single
class module represents a class (?). But I know the internal

That much is clear: you don't know VB6 very well, or else you wouldn't have
answered as you have. No matter, at least you appear to listen, to be
reasonable.

Adding polymorphism to COM might be possible, but would result in a very
ugly implementation - performance and usability wise.

You needn't add polymorphism to COM, you need only add it to the compiler. COM
is essentially an interface, not a compiler.

.NET is all about language interoperability, enhancing the COM model
would break compatibility with all languages currently using the COM
object model.

You don't think it could adapt to name mangling?

.NET objects? Why not?

Certainly possible. Though COM objects are reference counted and .NET
objects are managed. Which is not quite the same.

What *is* the COM interop, isn't it .NET interfacing to COM? You don't think
that the reverse of the COM interop is technically possible?

And VB Classic already
*has* object classes...Why couldn't better backwards compatibility have been
retained? Why couldn't the extensions have been true extensions to the language
instead of a different language?

As I've already posted IMHO true backwards compatibility could have been
done by introducing some kind of mixed mode for VB as it's the case for
C++.

Ok. Thank you.

Most VB applications are GUI centric. All these applications could only
be compiled to native code or only to managed code if you are using .NET
controls. By mixing them you would loose the ability to compile to both
native and managed.

I'll stipulate for now (without blanket acceptance) that mixed native/managed
code sections in the same application might be difficult to automate for VB, but
maybe provision could have been made for us to choose for each application,
without dropping support for old apps?

That shouldn't be an excuse for all the unnecessary changes, but all
applications using GUI centric code would IMHO have been broken anyways,
even if the language would have been 100% compatible.

Maybe, but dropping support for VB Classic completely sure wasn't a good move.

.NET is a different platform. Compiling the "old" code to .NET is a nice
feature but IMHO doesn't help that much. If you are using .NET you are

I think it would have helped gain acceptance for .NET. But the other matters of
EULA, DRM and "*we* own ~your~ data" might need to be reversed.

tied to it -> no way back to native code. There's no single language
which is able to do that. Only native .NET compilers would make that
possible - IMHO.

I see no obvious technical reason that a hybrid compiler wouldn't be possible. I
see lots of marketing and selfish strategic reasons this was not done. IMHO.

Regards,
_______________________
Michael B. Johnson
.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: subroutine stack and C machine model
    ... Use a compiler optimizer ... higher determinism means that optimizer has more information. ... C programmers like to brag that their "language" is more ... prospective computer science majors at Princeton. ...
    (comp.lang.c)
  • Re: "STL from the Ground Up"
    ... are not features of a language. ... To support reflection you make a compiler embbed type and functional information in the compiled program. ... When the OCaml compiler is given a complicated nested pattern match it ... virtual const Base *clone= 0; ...
    (comp.programming)
Loading