Re: VB6, VB2005, or Something Else?


"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
news:e2Qi08aQGHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
Dan Barclay wrote:
"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message That's
known as ETC (Evil Type Coercion). Don't get me started... it's one of
the changes made at VB4. MSBasic has always allowed coercion of numeric
types, but adding strings to the coercion mix caused more problems than I
care to think about.

And the data type involved internally is a variant - I suppose. ;-)

Nope, it was actually the type it said it was. As I said, that
functionality has been supported as far back as CP/M and DOS products.
Conversions were done, explicitly, with code under the hood. You could see
that from the ASM output of the DOS compilers.

Automatic type conversion is IMHO not a good idea, I think we agree in
this point.

However, at the same time they did break $trings. Prior to VB4 there was
no byte data type so the *only* documented way to handle binary data was
with the $tring. That has been the case since CP/M versions of MSBasic.
At VB4 MS *redefined* this fundamental data type to use UNICODE under the
hood along with zillions of calls to WideToNarrow...() and friends at the
boundaries. They documented that this could corrupt binary data. So,
along with ETC we get UNIMESS. You can google on those if you wish.

Thanks for the links. Storing binary data into strings is an abuse by
itself. If you hadn't any chance to store binary data in another way, then
it's at least an excuse to do so ;-). By the way some months ago some
colleagues of mine stored binary data in C++ in the string class, because
it was so easy too handle (sigh).

Do not confuse data types with their names.

What they should have done in VB (and in your friends C++ case) was *define*
the right data types. If you want a Text data type, define it as Text.
There is nothing wrong with keeping the definition of BinaryString. MS
should have done so, and added a Text (real Unicode) data type.. Repeat
after me "A New Type Of Data Requires a New Data Type!".

I know why they, Microsoft, did the changes, since Windows NT is Unicode
based, the OS had to permanently convert strings to Unicode when passed to
a Win32 API function. But the main reason is that many human languages
need Unicode support, to represent their characters properly.

Actually, much of the API work still used ansistrings<g>. They didn't
really get Unicode, even though they screwed the type definitions trying.

They could perhaps have used some internal representation like Delphi -
holding both strings in Unicode 16 bit and ANSI 8 bit. That shouldn't have
broken the binary data and additionally would have prevented need for the
OS to permanently convert strings.

As I said above, which I recommended at the time, if you have "a new type of
data...."

should not be. It's one thing to recode for performance. It's quite
another to recode because code is simply broken.

Language behavior changes IMHO cannot be prevented over the lifetime of a
language. But I agree they should be only (!very!) slightly and the
compiler should warn about code that is affected by this changes.
E.g. in C++ this has happened to many times. E.g. for (...) scope.
By the way in Delphi IIRC too ;-) - look at 16 bit Delphi and 32 bit
Delphi.

I agree, they can't be absolutely prevented. It happens all the time with
all languages, and most have a deprecation process. I even defined reasons
to change, and a process to implement it, in my paper. Some detractors say
those of us who are looking for LS don't think *any* change should be made.
They simply haven't been listening.

later on released. Delphi can't do that automatically and pinning is not
a good thing to do in .NET either, if it can be prevented.

Delphi *doesn't* do that and I hope it never does. To say it can't do
that is incorrect as I'm sure you know. Pointers don't belong in the
.Net world IMHO.

It can't do that let's say "correctly", because the pointer is spread over
all the source code. In C# for example you have to mark a function as
unsafe to use pointers. The compiler knows when it can release the
pointers. Delphi would have in the worst case to "pin" the data forever,
which surely would be the worst thing to do. So yes, they don't better
support automatic pointer pinning.

Fortunately, I don't think they have plans to pin willy-nilly. My hope is
that they can avoid moving pointers at all, but there may be a need for
unmanaged code that requires it at some point.


[...]
UI code is easy to reproduce for the most part.

If it's only UI code yes. But if it's framework code (lists, base objects
etc.) then it's the nearly the same mess if the framework changes as it
would be if the language changes.

<GASP> You mean the framework may change???

FWIW, I've tried to practice "safe coding" by wrapping everything that has
to go outside the core language. Even straightforward API calls aren't
found just sprinkled in my existing code. Silly me, I thought that would
help me when I needed to move to platform.next. I'd just rewrite the
wrappers and move on. Then they changed the language itself. Who'd a thunk
it.

I've seen lots of "example" code that has about as much framework in it as
it does language function. Even when built-in language functions do the
same thing I see framework! Self.Shoot.Foot IMHO

Even though I didn't get complete protection from that strategy, it's still
a good one. I'll be wrapping framework "stuff" as much as I can. That
strategy worked for CP/M to DOS, then again from DOS to Win16, and then to
Win32. That it didn't work going to .net was an abberation.

Dan


.

Relevant Pages

  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)
  • Re: Bye bye CF.Net for Delphi dev?
    ... deliver it in a readily usable form for .NET developers. ... believe the Delphi language could offer great things on the .NET platform, ... It's also a framework. ... abstracts them from the Windows OS. ...
    (borland.public.delphi.non-technical)
  • Re: pointers?
    ... There's absolutely nothing abstract in pointers. ... Take the C array: if you write ... To the assembly language programmers who were the first generation adopters of C, this mental mapping was very tight. ... Forth gained the most traction on machines like the IBM 1130 and the Data General Nova. ...
    (comp.lang.forth)
  • Re: If you cant write Text2.Text = Text1.Text, then VB clone is no good
    ... tester for OS/2 (which became a lead-in to beta Windows) and I was hooked. ... also distaining FORTRAN (a useful niche language for mathemetical ... C-geeks - Why because of the VB-ness of the .Net Framework and IDE. ...
    (comp.lang.basic.visual.misc)
  • Re: another day, another patch ...
    ... windows weenies started to graduate from being teenage videogame players into application programmers and system managers. ... Would you blame the language? ... But you are then making that code REALLy ugly and dangerous (an non portable because assumption of 32 bit pointers). ...
    (comp.os.vms)
Loading