Re: VB6, VB2005, or Something Else?

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.
If you would enhance the COM model to support all that features, older languages/COM objects couldn't use them properly. You would break all existing COM code, if you would use the new features. And why introduce another object model - .NET is already a new one ?

I don't understand the object model in VB6 very well. Obviously a single class module represents a class (?). But I know the internal implementation of COM very well. It's based on interfaces and derivation (needed for polymorphism) is just "simulated" through method delegation.
Adding polymorphism to COM might be possible, but would result in a very ugly implementation - performance and usability wise.

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

.NET objects? Why not?

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

They did successfully build the COM interop, after all. 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++.

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.

The "framework" used by VB could certainly have been ported to .NET. Which would have introduced another framework, like it's been the case for Delphi. They have not chosen to do so. Because of resources, because they wanted to have a single platform.

Breaking the framework is like breaking the language, I've realized that with my C++ programs from another vendor, which hadn't separated GUI centric code.

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.

And supporting on the other side native compilation for .NET applications is not (yet) possible.

..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 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.

[...]
Michael B. Johnson

Andre
.

Relevant Pages

  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OO
    ... I certainly want more errors detected at compile time, ... > advocate reaching that goal through beefier type systems. ... in a procedural language, or in an object based language. ... Relativistic mechanics - solves the transaction thing, ...
    (comp.object)
  • Re: Teach myself C++.
    ... That seems to be an objection to the quality of implementation of ... The language IS the compilers. ... should be possible to compile some code more than once, ... I'd say that string handling is something most other languages get ...
    (sci.crypt)
  • Re: dynamic vs. static: the age-old debate
    ... necessary to compile a program, ... inseparably related to either dynamic or static typing, ... otherwise static language, and with similar effort, can write a largely ... I have the feeling you are not separating semantics and implementation; ...
    (comp.lang.misc)
  • Re: c#.net or vb.net
    ... Both C# and VB.NET compile to the _same_ IL don't they? ... developers using any particular development tool might make the body of code ... for a particular project doesn't make the language itself more "powerful," ... although that situation might make it more popular. ...
    (microsoft.public.cert.exam.mcad)