🚀 go-pugleaf

"D*lphi" <spam.delphi@not.here> wrote in message
news:3C66F542.8080305@not.here...
> VB werkt alleen maar met Variants.

Hahahahaha, sta me toe even in een deuk te liggen van't lachen.
Je zit hier VBScript met Visual Basic te verwarren; de twee dingen
zijn compleet vershillend.
Je zou eens de Visual Basic Language Reference moeten vastpakken
en eens zoeken naar de volgende keywords: Dim, Private, Public,
Global, Static, Long, Integer, Byte, String, ...

> Je hoeft nix expliciets te declareren.

Als je Option Explicit aanzet (iets wat elke degelijke VB programmeur
doet) hoeft dit wel.

> En zelfs als je Option Explicit definieert hoef je aan een variable geen
> type mee te geven?!?

Omdat dat ook niet de bedoeling is van Option Explicit... OE betekent
dat je elke variabele die je gebruikt moet definieren.
Als je een variabele definieert als
    Dim myvar
dan heb je myvar gedefinieerd als een Variant.

> Ja, Delphi, Java, etc. hebben ook al jaren properties.

Java heeft geen properties. Daar moet alles gebeuren via get en set
_methodes_.

> > Visual Basic moet zo geen compiler warnings geven omdat ze niet dezelfde
> > problemen heeft als Delphi :-)
>
> en Visual Basic heeft weer andere problemen die Delphi weer niet heeft :-)

Ongetwijfeld, maar elke taal heeft wel een of ander probleem tov. een andere
taal.

> Gelukkig, kun je in VB.NET niet meer runtime de code aanpassen. Yes,
> yes, dat zal die VB 'programmeurs' eens leren om eindelijk eens goed te
> programmeren :)

Runtime code aanpassen??? De VB runtime bestaat uit een aantal gecompilde
DLL's; je kan er dus niets aan aanpassen. Dit is exact hetzelfde In VB.NET
(di, een aantal gecompilde DLL's) en ongeveer elke andere Windows
programmeer taal (inclusief Delphi; die gebruikt de Win32 API als runtime).

> in VB6 draait de applicatie niet in een apart proces maar in de context
> van VB, wat zwaar irritant kan zijn. <SNIP>Applicatie crash -> VB crash
> -> weg laatste wijzigingen.

Eerst en vooral is dit enkel van toepassing als je je programma vanuit de
IDE
runt.
Ten tweede, zoals Rene al aangaf, kan je de IDE instellen dat die telkens
alles
opslaat voordat hij het programma uitvoert.
Ten derde, als je enkel de VB methodes gebruikt (dwz, geen API functies)
dan kan je IDE nooit crashen door je programma. Alle fouten (zoals
bijvoorbeeld
deling door 0) worden zonder probleem opgevangen door de IDE.

> Leidt alleen maar tot interne
> fragmentatie van VB, wat uiteindelijk moeilijk te beheren valt en
> uiteindelijk tot het crashen van VB lijdt.

Interne fragmentatie?? :-) Complete nonsense...
Als je op de 'Play' knop druk in VB, dan start Visual Basic zijn
Interpreter.
De enige code die je IDE kan doen crashen is bij het gebruik van API
functies
(bijv. een CopyMemory doen van of naar een geheugenplaats waar je programma
geen toegang tot heeft). Dan is de standaard reactie van Windows om een
proces
af te sluiten (tenzij er een UnhandledExceptionFilter geplaatst is, wat niet
het geval is).


Mvg,
Pieter Philippaerts