Re: VB language extensions wishlist

Hi,

Pavel Minaev wrote:

What features would you like to see in a next version of classic VB,
assuming such a thing would happen? Please restrict yourself to
language features and base libraries (such as e.g. Collection), not
IDE or task-specific libraries (UI, database access etc).

First I must say I would really appreciate if someone (you?) is willing to make a VB Classic successor. I even would put some of my time into such a project for helping where I can.

My hopes from such a new VB compiler are:

- Being able to use my old source code without alteration. A new compilation under the new compiler produces a new executable under the new runtime. This new runtime and compiler, in contrary to the old compiler and runtime, are not owned by Microsoft and so can be developped, adopted to new needs (eg those new versions of MS operating systems impose) and getting new features. In a sense: they make VB apps working also in the future.

Now to my wishlist (some items may be already doubled by others).

Absolutely indispensible is *full* compatibility to VB classic. Without that I do not see any sense in such a project. With compatibility I mean:

- Existing source code (as well as complete projects using the classic project files) must compile *without any alteration* (the need of setting some global compiler switches in code would be acceptable) and work as expected (eg classic file handling must produce the same result on file inclusive eg field padding, string conversion, array length storage etc).

Acceptable would be a solution where a classic project is "imported" or converted to the project structure the new compiler needs or has (but again this import should be fully automatic without the need for the developer to change things).

- Existing VB classic in and out of process COM server binaries (relying on the VB classic runtime) must be usable from projects compiled with the new compiler. The existing server binaries may be compiled to P-Code or native code. Such mixed projects (new project compiled or old project recompiled with the new compiler and additionally classic COM server binaries) must be possible. They of course would depend then on two runtimes: the classic one and the new one. Also of course new projects (new in the sense that they are compiled with the new compiler, but eventually using the same source code that was used for the classic compiler) must be able to use all other kinds of COM servers and COM components VB classic was able to use, using the same classic code for using them.

The new compiler may compile to native code only (for me p-code is not necessary).

The compiled code should run on a runtime environment. This runtime environment should be xcopy-deployable. No "registering" of the runtime is necessary. So a project could use a "private" copy of the runtime.

The new runtime should enable a project to instantiate COM objects without using the registry directly from the binaries file (this is already possible with VB classic, but not so easy doable). There eg could be an overloaded new operator which takes as extra arguments the (possibly remotely located) file name and the ProgID or the ClassID of the object. Of course those arguments may be wrapped in string variables.

Private copy of a runtime and registryless instantiation of COM objects would enable eg to run complete applications from a changeable media like an USB-stick.

No attempt should be made to "preserve" bugs of the classic environment. Those who recognized bugs in the runtime or the compiler should already have written a working workaround.

Now on to the extensions. Of course they must not hinder the compilation of unaltered classic code (a classic/new mode compiler switch would be acceptable for me).

- More basic types: 64 bit integers, for all integers unsigned counterparts, a standalone decimal type (not wrapped in a variant, 8 byte at least, additionally a 12 byte type) with settable fractional part, perhaps a more than 8 byte float, a bitfield type (perhaps of variable length). Eventually a complex number type (4 and 8 Byte floats).

- Those new basic types must fit into the classic UDT (struct) scheme. Layout of structs should be user settable (eg padding). Perhaps unions.

- Pointers! Typed to basic types, structs, array and string data, untyped (void) to unspecific memory. Untyped pointers should be castable to a typed one (so that any memory location can be accessed via typed pointer). Typed function and method pointers.

- A more expressive "Declare" syntax. It should be as expressive as IDL, allowing VB access to eg dlls having C-call convention, to all (inclusive the new ones) basic types and structs of them, with no automatic string conversion (one can specify wether VB shall use BStrings, traditional C-Strings etc). Also it should be settable wether (as with imported typelibraries in VB classic) the dll containing the methods is preloaded on program start by the windows program loader or on demand, when the first time a method of this dll is accessed in code. Also the file location of the dll should be specifyable (in a variable, with relative or absolute pathes).

Also a namespace separation for such declares is needed: per attribute it should be selectable wether a declared method (or its alias name) is invisible or globally visible in the project or only visible when fully qualified (in class-like syntax: MyDll.MethodX, with intellisense assisting the selection of a method in MyDll). Namespaces for common BAS-modules are also welcome. Aliases for Namespaces are welcome too (instead of using MyVeryLongPrefix.MyMethod use Set NamespaceAlias Shrt For MyVeryLongPrefix: Shrt.MyMethod). Also access using the With Syntax (With MyVeryLongPrefix: .MyMethod: End With).

There also some kind of "typed" enum (each member of the enum has individual type like string, 16 Bit int, etc) could help. These again "namespaced".

If possible, the Declare-Syntax should be extended such that C++-classes can be instantiated and used by VB.

In cooperation with typed method and function pointers callbacks should be made available per Declare.

It should be possible to treat a source file containing only Declares as separate compilation unit which can be distributed and imported in compiled form (much like a type library).

The goal must be to be able to easily access as many non-COM dlls as possible. Think of the immense amount of useful open source code out there, which often can not be accessed by VB programs, because they use the C calling convention, have types VB does not have and so on.

This would help tremendously. People from the open source scene eventually would jump on the VB waggon and provide "typelibs" for their work. Or some other of the VB community will be easily able to wrap an open source dll in a declarative unit, compile them and distribute them. For VB programmers a whole new world would open up. Masses of tools would be available. The situation nowadays is really sad: masses of open source dlls are wrapped for use in Ruby, Python, and so on, but almost no wrappers are available for VB classic. I am keen enough to say that this is a kind of killer point for a new VB.

- Namespaces also for common BAS-modules

- A better collection: two of them, one with small memory footprint for mass use, another one more fat but of more general usability. The small one should have typed members (all members of one instance have same type, structs and typed object references as type ok), the fatter one has variants as member type. Both should have methods for testing the existence of an entry (by key and index) and retreiving the keys (by index and for-each enumeration of all keys). Values must be mutable. In VB classic they are immutable (one has to remove an entry and recreate it for changing the associated value).

- Single and double linked lists with their administration and access methods. One kind with typed members (incl. structs and objects), one with variants.

- A good builtin hash function

- Builtin sort methods (QuickSort, ShellSort, HeapSort and InsertionSort) operating on basic types with builtin quick swaps and comparisons, or arbitrary types accepting swap and comparing method pointers.

- Builtin window subclassing and hooking (key hooks, message hooks etc)

This leads us to forms and controls, a wide field.

- For windowed forms and controls including user controls much more messages than now need to be translated or derived into VB events (eg Activation, MouseIn, MouseOut, etc, a long list)

- A general message arriving event should be available for above (for those messages that are not translated to VB events and for future messages).

- Better assistance of runtime instantiation of windowed forms and controls. There are many control properties that currently are settable only at design time. Eg a text box loaded at runtime has fixed properties like being single lined. There is no way to dynamically instantiate a text box that is multi lined. Instead of the simple Load mechanism classic VB provides a better one is needed that allows to set the same properties that can be set at desing time dynamically when instantiating at runtime. Forms also have properties that currently are only settable during design time and which needed to be made dynamically settable on instantiation.

- A true scrollable container control (not a picture box, not a user control)

- Scrollable forms and user controls

- All new of above and all existing scrollable controls react on MouseWheel messages.

- More controls, all what is fashionable nowadays :-). Seriously, simple things like a splitter control, more sophisticated things like menu bars with all nowadays common bell and whistles (built in the runtime, not separately), a simple, html formattable "rich text" box, and so on. Others will want some others too :-)

- A (much) better GUI layout system. Similar to .NET's or Borland's. Implemented eg. by additional control and form properties (like MinWidth, MaxWidth, PreferredWidth, DockPos, and the like) and/or layout managers (grid layout classes, and the like). My pet beef would be a layout manager that acts (in respect to layouting) like a Html renderer. I personally would prefer a layout manager system (layout classes and layout constraints describing classes attachable to forms and controls, not the route with additional simple layout properties).

- A system to make forms and controls easily adaptable to resolution (dots per pixel of the screen) changes and screen size changes (pixels wide and high). Also font size changes in a control should be handled.

- All controls (where applicable) should be able to act virtual in respect to their data. Eg it should be possible to instantiate a virtual list box with no data. The list box then demands data as necessary by a list box event or by evaluating a reference to a data container and retrieving the data from there.

- All controls (where applicable) should on demand be owner drawable. Eg a list box could be set to owner draw mode and then raises events each time items shall be displayed. Relevant data (like drawing area, perhaps data to be drawn) is passed to the event. In code then developer can draw. This would be immensely helpful for extending the base functionality of a control with simple means. Eg a list box such can act as font viewer, color selector, simple grid, and so on without hazzles.

- Also for those kinds of controls that show data textual and additionally for each entry can hold additional data (which currently is either of type Long or Variant or String) the type of this data may be any VB assisted type. Eg a list box then as item data can not only hold values of type Long, but also of any type. And this either strictly typed or multityped (using a variant).

- Own forms and controls should be derivable in the OOP sense. Eg a new control can be derived from the builtin textbox control as base class, inheriting all state, properties, methods and events from the parent, being able to add state, properties, methods and events and being able to override properties, methods and events.

Ok, now some OOP extension wishes. I fear there are not so much.

- Interfaces not defined as classes with empty bodies

- No need to implement each interface method. Interface methods not implemented in code should automatically return the COM "Not implemented" HRESULT.

- Class single inheritance (base class/parent). For COM a new interface is created automatically. Add constructs like Overridable, Final, Virtual.

- Better access to class *instance* methods and properties not using the IDispatch interface (which is to slow and not reachable for the non COM world). Direct access per vTable should be possible. Think of a typed method pointer to the method of a class *instance*. This should allow to use a class *instance* method as callback from a standard dll. The dll (or eg Windows via hook or message procedure) calls back to an intermediary having the necessary signature without the This parameter and no function return parameter (if it is a function). VB creates this intermediary stub, and, on callback, translates this to a call to a class instance method call the class instance can consume.

Ok, enough for today. I am really hooked on the idea someone could create a better classic VB. A VB that has future, exciting new features, which for them alone would it set apart again from the competitors as first class programming language world citizen, and additionally can consume its anchestor's code base to satisfy the millions sitting on billions (german 'billions', aka 10^12) of lines of code. I am sure the feature set I wished here is good enough to make it a major player again. And, if the new compiler does not come from Microsoft and has a reasonable licensing model, the open source community or at least the VB community would embrace it heartfully.

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
.

Relevant Pages

  • Re: ASP.NET application load time after some change
    ... The speed can also be affected by how much stuff is in viewstate. ... as Labels or Controls who have their value set in the Load event have no ... because the compiler only needs to compile it once. ... web.config) that can increase or decrease load time? ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET application load time after some change
    ... The speed can also be affected by how much stuff is in viewstate. ... controls such as Labels or Controls who have their value set in the Load ... because the compiler only needs to compile it once. ... load time takes, sometimes, three or four of minutes ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: foreach considered dangerous?
    ... a heterogeneous collection. ... controls that are owned by the control. ... >> The problem is that, without generics, you don't have a choice. ... > cannot be caught by the compiler. ...
    (microsoft.public.dotnet.languages.csharp)
  • FreeBSD 6.2 stable crasches when running dump on mounted snapshot.
    ... # CFLAGS controls the compiler settings used when compiling C code. ... # CXXFLAGS controls the compiler settings used when compiling C++ code. ...
    (freebsd-questions)
Loading