Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb im
Newsbeitrag news:3484
> Hallo Gerald
>
> anderes
> scheint mir,
> ;)
>
> Unsinn.
> VB 'erschwindelt' Module mit einem VB-sprachspezifischen Attribut,
> Assemblies sind also an die VB-DLL gebunden und 100% CLI-inkompatibel.
> Und alles derart sprach-spezifische ist nun mal 'erz-böse' by Design...

Das kann man nun so oder so sehen. Das Problem bringt ja die CLR so mit
sich. Will eine Sprache ein Feature bieten, daß die CLR nicht bietet, so muß
ja schon per Design getrickst werden. Die meisten Sprachen restriktieren ja
den eingebauten Funktionsumfang, aber eine Erweiterung ist schlichtweg nicht
möglich. Schon das Ausnutzen von Features bringt einen in die Gefahr
inkompatibel zu anderen Sprachen zu werden. Daher ja die CLS.

Erweiterungen sind also kritisch zu beäugen. So muß man als VBler ja leider
auf optionale Parameter verzichten, obwohl diese meist viel sinnvoller als
Überladungen sind. Man muß ja nur mal MessageBox.Show mit MsgBox vergleichen
und merkt gleich, wo man sich schneller zurechtfindet.

Mit dem nötigen Wissen kann man aber die Seiteneffekte abschätzen und die
sind bei Modulen wahrlich kalkulierbar. In C# sind sie zum Beispiel per
Modul.Eigenschaft verwendbar. Schließlich ist das ganze in der IL ja nur
eine Klasse mit nur statischen Eigenschaften.

Daß der VB Compiler hier mit Hilfe eines Attributes die Klasse für seine
Zwecke erweitert ist nicht böse, sondern genau das, wofür Attribute doch
geschaffen wurden. Objekte mit zusätzlichen, nur für bestimmte Einsatzzwecke
gedachte, Metainformationen auszustatten. In allen Applikationen wird dies
als ein geschicktes Werkzeug angesehen und genutzt, warum sollte ein
Compiler, als spezielle Applikation, dafür in Miskredit gestellt werden?

Vom rein technischen Aspekt sehe ich keinerlei Problem beim Einsatz von
Modulen. Problematisch ist da vielmehr die Les- und Warbarkeit von Code, die
bei unsachgemäßem Einsatz sehr stark leiden kann. (Habe da schon einige
Projekte wieder geradebiegen müssen...)

Ich setze, wie geschrieben, Module sehr selten und überlegt ein. Mag aber
die dadurch gewonnene Effektivität und Lesbarkeit.

Gruß
Gerald

> Das kann man nun so oder so sehen. Das Problem bringt ja die CLR so mit
> sich. Will eine Sprache ein Feature bieten, daß die CLR nicht bietet, so muß
> ja schon per Design getrickst werden. Die meisten Sprachen restriktieren ja
> den eingebauten Funktionsumfang, aber eine Erweiterung ist schlichtweg nicht
> möglich. Schon das Ausnutzen von Features bringt einen in die Gefahr
> inkompatibel zu anderen Sprachen zu werden. Daher ja die CLS.


wären 'VB-Module' eine sinnvolle, naheliegene und für viele Sprachen nützliche Sache,
wäre der Support dazu direkt in .NET eingebaut worden...
Aber VB-Module erfüllen diese Anforderung halt nicht,
da sie wohl auch nur einzig zur 'psychologischen Kompatibilität' mit VB.EX beibehalten wurden...

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>>> Diskussionen anregen (auf die ich nicht reagieren werde:-) )
>>> oder sich auf den Kopf stellen - Module _sind_ böse :-)).
>
>> Von einem Freund der geschweiften Klammern erwartet man ja auch nix
>> anderes
>> Die Diskussion hatten wir aber schon im Detail und für Dich, so scheint
>> mir,
>> ist sowieso jede VB Eigenart, die C# nicht hat, ein sinnloses Feature ;)
>
> Unsinn.
> VB 'erschwindelt' Module mit einem VB-sprachspezifischen Attribut,
> Assemblies sind also an die VB-DLL gebunden und 100% CLI-inkompatibel.
> Und alles derart sprach-spezifische ist nun mal 'erz-böse' by Design...

Nichts an Modulen ist sprachspezifisch! Das Attribut und
"Microsoft.VisualBasic.dll" sind .NET-Assemblies, das Resultat ist zu 100 %
..NET-konform. Zu diesem Zweck sind u.a. Attribute geschaffen worden! Es
steht jeder anderen Programmiersprache frei, das Attribut entsprechend zu
interpretieren oder dies nicht zu tun. Ist letzteres der Fall, bricht auch
niemandem ein Stein aus der Krone, da die Funktionalität des Moduls benutzt
werden kann.

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>> Das kann man nun so oder so sehen. Das Problem bringt ja die CLR so mit
>> sich. Will eine Sprache ein Feature bieten, daß die CLR nicht bietet, so
>> muß
>> ja schon per Design getrickst werden. Die meisten Sprachen restriktieren
>> ja
>> den eingebauten Funktionsumfang, aber eine Erweiterung ist schlichtweg
>> nicht
>> möglich. Schon das Ausnutzen von Features bringt einen in die Gefahr
>> inkompatibel zu anderen Sprachen zu werden. Daher ja die CLS.
>
> wären 'VB-Module' eine sinnvolle, naheliegene und für viele Sprachen
> nützliche Sache,
> wäre der Support dazu direkt in .NET eingebaut worden...

Ist er doch! .NET stellt Klassen, gemeinsame Mitglieder und Attribute
bereit, alles, was man braucht, um Module zu unterstützen. Wozu unter der
Haube zusätzliche Entitäten einführen, welche die Implementierung nur noch
erschweren?

> Nichts an Modulen ist sprachspezifisch! Das Attribut und
> "Microsoft.VisualBasic.dll" sind .NET-Assemblies,

Assemblies sind die blosse Verpackung -> hier irrelevant.
Nur auf deren Namen & Inhalt (Namespaces, Klassen,Methoden) kommt es an.
Und daran ist restlos _alles_ 100% VB-sprachspezifisch,
machen in keiner einzigen anderen Sprache einen Sinn.
(und ein grosser Teil ist sogar auch nur Altlast zur 'psychologischen Abwärtskompatibilität')

> Und daran ist restlos _alles_ 100% VB-sprachspezifisch,
> machen in keiner einzigen anderen Sprache einen Sinn.

Müssen sie ja auch nicht unbedingt - zumindest nicht für denjenigen, der
nicht im Sinn hat universelee Bibliotheken zu entwickeln.

> (und ein grosser Teil ist sogar auch nur Altlast zur 'psychologischen
> Abwärtskompatibilität')

....und für die Zukunft...:

http://www.panopticoncentral.net/arc.../10/11994.aspx


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de

LOOOOL :). Da is man mal 2 - 3 tage weg und? Man hat meine Frage ne
Diskussion losgetreten. Ich entschuldige mich mal dafür. Ich hab jetzt alles
gelesen und habe vergessen gehabt mein Modul als Public zu deklarieren. Das
war in VS2003 definitiv nicht nötig.
Assembly hin oder her. Ich denk das passt schon so :). Vielleicht sieht man
sich ja mal auf ner .NET Tagung oder so um das auszudiskutieren.

Bis denne und Vielen Dank an alle!

"Christian Engelhardt" wrote:
[..]