> C# Programmer's Reference -- How to: Use the 'My' Namespace
> <URL:http://winfx.msdn.microsoft.com/library/en-us/dv_csref/html/e7152414-0ea5-4c8e-bf02-c8d5bbe45ff4.asp>


Das alte Horror-Szenario:
Microsoft.VisualBasic.dll

in C# referenziert nimmt kein echter C# Profi ernst.
(und die 'My'-Krücke ist so sogar stark verkrüppelt!)

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
> In keinster Weise hat die 'My'-Krücke etwas mit C# zu tun.

Sprechen wir in ein paar Jahren noch einmal darüber, wenn sich dein Frust
etwas gelegt hat, weil C# auch 'My' unterstützt.

Hallo Joachim!

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
>> C# Programmer's Reference -- How to: Use the 'My' Namespace
>> <URL:http://winfx.msdn.microsoft.com/library/en-us/dv_csref/html/e7152414-0ea5-4c8e-bf02-c8d5bbe45ff4.asp>
>
> das geht einher mit Bauchschmerzen und Brechreiz :-(
>
> Zitat daraus:
>
> "Not all the classes in the My namespace may be called from a C#
> application: for example, the FileSystemProxy class is not compatible. In
> this particular case, the static methods that are part of
> System.IO.FileSystem (also contained in the VisualBasic.dll) can be used
> instead.

Nun, dies ist darauf zurückzuführen, dass C# das 'My'-Compilermerkmal nicht
unterstützt -- aber das wird sich ja vermutlich in Zukunft ändern.

Hallo Herfried,

> ... diese Mehrheit versucht, wie man an 'That' erkennen kann, ...

Upps? Was ist "That"?


Viele Grüße

Harald M. Genauck

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

Hallo Herfried,

>> Die "große Sünde" hat Microsoft wohl damit begangen, My in den
>> VB-Namespace zu legen, statt in den System-Namespace...

> Nun, das wird nicht zuletzt damit zusammenhängen, dass 'My' zum Teil auch
> ein Funktionsmerkmal des Compilers ist. Zumindest diese Teile
> ('My.Forms') lassen sich schwer in das .NET Framework integrieren.

Forms hätte ja nicht zu My gehören müssen. My als Namespace im Framework
und Forms ein Sprach-Objekt in VB, so wie in VB-Classic auch. So what?


Viele Grüße

Harald M. Genauck

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

Hallo Harald!

"Harald M. Genauck" <hmg.ng.entfernen> schrieb:
>> ... diese Mehrheit versucht, wie man an 'That' erkennen kann, ...
>
> Upps? Was ist "That"?

Wie bereits in einem anderen Beitrag dieses Threads genannt:

<URL:http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=8#CSharp>
-> "My for C# 2.0"

Hallo Harald!

"Harald M. Genauck" <hmg.ng.entfernen> schrieb:
>
> Ich sehe keinen großen Unterschied zwischen der Philosophie von und Basic
> und Python. Eher im Gegenteil: Python scheint mir lediglich das Resultat
> einer Vereinfachung aus der Sicht von C/C++ zu sein, die Basic zufällig
> bis auf leichte Syntax-Unterschiede gleich gekommen ist. Dynamische
> Datentypen mit impliziter Typumwandlung kennt VB auch - in VB Classic
> waren es die Variants, in .NET ist es schlicht Object. Bezüglich von
> anscheinend "jüngeren" Sprachelementen wie Listen, Dictionaries usw. ist
> VB.NET sogar besser dran als Basic an sich und VB Classic - und als
> Python.

VBA mit der Möglichkeit der dynamischen Codeerweiterung und -manipulation
(VBE mit 'CodeModule') ging auch schon stark in die Richtung dynamischer
Programmiersprachen. Interessant ist, dass diese Konzepte, die in BASIC eine
gewisse Tradition haben, oft als schlecht und unsauber dargestellt wurden,
sich aber andererseits anscheinend neuerdings ein "Hype" darum entwickelt.

> Die "Leichtigkeit" der Sprache ist eine Sache, eine andere ist das
> Entwicklen von Anwendungen mit GUI und Nutzung von System-Features. Und da
> werden auch dynamische Sprachen wie Python und eben auch VB aus sich
> heraus kaum RADiger werden können. Das geht nur über zusätzliche
> Bibliotheken, die entweder auf dem .NET-Framework aufsetzen oder formal in
> selbiges integriert werden. Ob nun der Namespace einer solchen Bibliothek
> mit "System" beginnt (und damit scheinbar die Integration ins Framework
> "beweist"), oder ob er "Kuwiopaz Dollbunt" lautet, oder ob er "Microsoft
> Visual Basic" heißt, spielt wohl kaum ernsthaft eine Rolle.

Dem stimme ich voll zu.

> Die "große Sünde" hat Microsoft wohl damit begangen, My in den
> VB-Namespace zu legen, statt in den System-Namespace...

'My' ist eben mehr als ein Namensraum und setzt voraus, dass z.B. der
Compiler entsprechend angepasst wird. Vielleicht wird Microsoft bei Orcas,
das ja RAD zum wichtigen Ziel hat, auch der C#-Compiler entsprechend
erweitert, sodass 'My' (oder 'That' ;-)) integriert werden kann. Wie die
Bibliothek heisst, ist doch wirklich vollkommen egal.

Hallo Herfried,

> VBA mit der Möglichkeit der dynamischen Codeerweiterung und -manipulation
> (VBE mit 'CodeModule') ging auch schon stark in die Richtung dynamischer
> Programmiersprachen. Interessant ist, dass diese Konzepte, die in BASIC
> eine gewisse Tradition haben, oft als schlecht und unsauber dargestellt
> wurden, sich aber andererseits anscheinend neuerdings ein "Hype" darum
> entwickelt.

BASIC ist nun mal "pfui" in den Augen aller "richtigen" Programmierer...

Auch die naheliegende Vorgehensweise von BASIC-Einsteigern, Daten (also
auch numerische Werte) im Klartext-Format und dann auch noch in Textdateien
zu speichern wurde (zumindest vor etlichen Jahren) ewig müde belächelt.
Inzwischen ist XML *der* Hype...

>> Die "große Sünde" hat Microsoft wohl damit begangen, My in den
>> VB-Namespace zu legen, statt in den System-Namespace...

> 'My' ist eben mehr als ein Namensraum und setzt voraus, dass z.B. der
> Compiler entsprechend angepasst wird. Vielleicht wird Microsoft bei
> Orcas, das ja RAD zum wichtigen Ziel hat, auch der C#-Compiler
> entsprechend erweitert, sodass 'My' (oder 'That' ;-)) integriert werden
> kann. Wie die Bibliothek heisst, ist doch wirklich vollkommen egal.

Ist schon klar - hatte ich ja anderer Stelle auch schon angemerkt... Aber
wir müssen doch jetzt 'My' nicht dogmatisch als Monolithen betrachten,
oder?
;-)


Viele Grüße

Harald M. Genauck

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

Hallo Harald!

"Harald M. Genauck" <hmg.ng.entfernen> schrieb:
> Auch die naheliegende Vorgehensweise von BASIC-Einsteigern, Daten (also
> auch numerische Werte) im Klartext-Format und dann auch noch in
> Textdateien zu speichern wurde (zumindest vor etlichen Jahren) ewig müde
> belächelt. Inzwischen ist XML *der* Hype...

:-)

>>> Die "große Sünde" hat Microsoft wohl damit begangen, My in den
>>> VB-Namespace zu legen, statt in den System-Namespace...
>
>> 'My' ist eben mehr als ein Namensraum und setzt voraus, dass z.B. der
>> Compiler entsprechend angepasst wird. Vielleicht wird Microsoft bei
>> Orcas, das ja RAD zum wichtigen Ziel hat, auch der C#-Compiler
>> entsprechend erweitert, sodass 'My' (oder 'That' ;-)) integriert werden
>> kann. Wie die Bibliothek heisst, ist doch wirklich vollkommen egal.
>
> Ist schon klar - hatte ich ja anderer Stelle auch schon angemerkt... Aber
> wir müssen doch jetzt 'My' nicht dogmatisch als Monolithen betrachten,
> oder?
> ;-)

Sicher, 'My' hat viele Facetten, aber es ist eben nicht einfach /nur/ eine
Namensraumduplizierung, die einfach in die Klassenbibliothek des .NET
Framework eingegliedert hätte werden können. Wäre 'My' Teil des .NET
Framework und könnte von C# aus nicht benutzt werden, würden sich die C#ies
wohl benachteiligt vorkommen. Da ist es für C#-Benutzer doch beruhigender,
'My' an VB.NET gebunden zu wissen und darüber herziehen zu können.

Hallo Thomas,

> >> Ja, die Grüppchen bei MS sollten mal miteinander reden, statt
aneinander
> >> vorbei alles mehrfach und kreuz und quer zu programmieren.
> > Vielleicht haben sie ja doch miteinander geredet und die Differenz
zwischen
> > VB und C# bewusst belassen.

Das würd ich sogar sehr stark vermuten.

> die Tatsache,
> das die My-Krücke

Warum ist das eine "Krücke"?

> nur im VB-Namespace/Assembly eingebaut wurde,
> sagt dazu IMHO ja eigentlich schon restlos alles aus...

Was sagt das denn aus?

> Ich persönlich halte die My-Krücke als
> völlig missratene Kurschluss-Handlung
> aufgrund unseriösem Kunden-Feedback...

Was ist denn ein "unseriöses Kunden-Feedback"?

> (ala DAU: "...ich finde die Klassen nicht in den BCL-Namespaces")

Ich bin immer wieder verwundert, welche Statements in Bezug auf VB man hier
immer wieder mal lesen kann. Ich benutze eine Programmiersprache als
Werkzeug zur kommerziellen Programmentwicklung. Stabilität der Anwendungen
und ein höchstmögliches Mass an Produktivität bei der Erstellung solcher
Anwendungen zählen dabei zu den wichtigsten Kriterien. Eine Diskussion
darüber, ob eine bestimmte Syntax in einer Programmiersprache gut oder
schlecht sei, nur weil sie nicht mit der in einer oder mehreren anderen
Programmiersprachen übereinstimmt, halte ich ehrlich gesagt für ziemlich
schlicht und albern und ich würde mir auch wünschen, wir blieben künftig von
solch wenig hilfreichen Diskussionen verschont.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)

Hallo Thomas,

ich würde Dir doch mal raten, Deine hier losgelassenen Statements ohne jede
Aufgeregtheit und in Ruhe mal selbst zu lesen. Dabei würde Dir vielleicht
auffallen, dass Du Dir fast mit jedem Satz selbst wiedersprichst und das,
was Du für Argumente hältst nur Deine scheinbar intensivst gepflegten
Vorurteile gegen alles was mit VB zu tun hat, sind.

> 1.) die My-Krücke ist nicht in den offiziellen .NET BCLs,
> sondern (schon wieder) eine 'private' Zusatz-Bastlerei!
> (siehe Namespace & Assembly)
>
> 2.) die My-Krücke ist 100% frontal gegen das Ziel eines
> (insbeso auch im Sinne der [portablen] CLI/CLS)
> konsequenten .NET _Frameworks_ gerichtet!

Es gibt tausend Dinge, die sich mit Mitteln des .net-Frameworks alleine
nicht lösen lassen. "Profis" wissen das und sind mit solchen Dingen täglich
konfrontiert. Deiner Logik zu Folge, dürfte man dann für solche Aufgaben gar
keine Programme schreiben.

> 3.) wurde die My-Krücke IMHO + AFAIK einzig auf
> sturen Zwang einiger 'lern-unfähiger' Kunden hin gebaut.
> (exakt 100% vergleichbar mit der kindischen,
> zum Glück gestorbenen Zwängerei einer VB6-Petition !)

Wenn Du es für "kindisch" hältst, dass jemand, der seinen Kunden gegenüber
in der Pflicht steht, darauf achtet, dass deren Programme über einen
vernünftigen Zeitraum weiterhin einsatzbereit bleiben sowie gepflegt und
gewartet werden können, dann zeugt das nicht gerade von Professionalität.
Ich weiss nicht, ob Du schon mal mit einem Kunden einen Vertrag über die
Erstellung einer Software erstellt hast, aber Deine Statements hier lassen
mich vermuten, dass Du noch nicht mit solchen Aufgaben betraut warst.

> 4.) die My-Krücke ist mit den VB6-Fn Kompat.-Krücken vergleichbar;
> Noch fataler, das Problem hat sich dadurch bereits verdreifacht!...

Welches Problem denn?
Wenn ich es recht verstehe, hast nur Du damit ein Problem. Das sollte aber
doch nicht der Maßstab für den Rest der Welt sein. Ich glaube, den Rest
Deiner Statements zu kommentieren kann ich mir getrost sparen.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)

Hallo Herfried,

> > Nochmals,
> > 'My' ist nur eine primitive, sinnlose Namespace-Duplizierung.
>
> Dann muss ich bei dir leider vollkommene Unkenntnis von 'My' konstatieren.

Herfried, ich vermute dass sich diese Unkenntnis nicht nur auf "My", sondern
mehr oder weniger auf den gesamten Umfang von VB bzw. VB.net bezieht. Anders
kann ich mir solche Statements nicht erklären.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)

Hallo Peter

du bist etwas spät & OT, daher :

> Ich bin immer wieder verwundert, welche Statements in Bezug auf VB man hier
> immer wieder mal lesen kann.

es geht nicht um VB, sondern VB.NET...


> ob eine bestimmte Syntax in einer Programmiersprache gut oder schlecht sei,

es geht per Definition nicht um die Syntax/Keywords, sondern um Zusatz-Funktionen/Libraries,
die so nicht ins .NET-Zeitalter gehören.

Hallo Joachim,

mich würde wirklich mal interessieren, was Du und Thomas so den ganzen
Arbeitstag über machen.
Ich kann mir jedenfalls nicht vorstellen, meine wertvolle Arbeitszeit mit
völlig sinnlosen Diskussionen über bestimmte Funktionalitäten in
verschiedenen Programmiersprachen zu verschwenden. Wem nützt es, wenn
irgendeiner meint "My" oder was auch immer eine Programmiersprache an
Eigenheiten bietet, sei gut oder schlecht?
Die Entscheidung für eine bestimmte Programmiersprache wird jeder irgendwann
mal gefällt haben, nachdem er alle aus seiner Sicht wichtigen Pro- und
Kontra-Argumente gegeneinander abgewogen hat. Wenn er sich für VB.net
entschieden hat, hat er sich auch für "My" entschieden. Er wird wohl gute
Gründe dafür gehabt haben.

Das hier ist eine Newsgroup für VB.net.
Ergo ist anzunehmen, dass hier Probleme und Aufgabenstellungen rund um
VB.net erörtert werden und die Fragesteller für ihre Arbeit oder meinetwegen
auch ihr Hobby verwertbare Antworten erhalten wollen. Ganz sicher aber
wollen sie keine schon fast an frühzeitliche Kreuzüge erinnernden
Missionierungsversuche über sich ergehen lassen. In meinen gut 40 Jahren
Berufspraxis habe ich schon eine Vielzahl an Programmiersprachen
kennengelernt. Das Ergebnis dieser Erfahrungen ist, dass ich VB für eine
Sprache halte, deren Produktivität von kaum einer anderen Sprache erreicht
wird. Deshalb auch meine Entscheidung in meinem Unternehmen VB/VB.net
bevorzugt (aber nicht ausschliesslich) als Programmiersprache(n)
einzusetzen. Ich meine, Diskussionen um Dogmen sollte man den Vertretern
verschiedener Religionen überlassen. In einem technischen Bereich, wie dem
unseren halte ich solche Diskussionen für völlig überflüssig und
entbehrlich. Auf die Idee, ellenlange und fruchtlose Diskussionen Pro und
Contra "My" zu führen, käme ich gar nicht.

> Als .NET-Programmierer sollt man .NET-Beispielcode nachvollziehen können,
> der entweder in VB.NET oder C# geschrieben worden ist.

Von einem Programmierer, der Programme mit VB.net schreibt, erwarte ich,
dass er diese Programmiersprache hinreichend beherrscht um damit die ihm
anvertrauten Programme zu schreiben und auch zu pflegen. Wozu soll er dafür
das gleiche Wissen über C# haben?


> VB-Programmierer, die
> sich auf My und Basic-Altlasten eingeschossen haben, werden dann 90% der
> Beispiele im Internet usw. nicht verstehen können.

Wenn ich oder irgendein anderer einen Programmierer einstellt, dann wird es
ihm erst mal relativ egal sein, ob der irgendwelche Beispiele aus dem
Internet versteht. Ein Programmierer wird eingestellt, um eine oder auch
mehrere ganz genau festgelegte Aufgaben zu bearbeiten. Wenn dafür gute und
fundierte VB-Kenntnisse erforderliche sind, dann werde ich den nicht fragen
ob und wie gut er C# beherrscht.
......
......

> Wenn es Code gibt, der allgemein benötigt wird (siehe Ausgangsthema), dann
> gehört der ins .NET-Framework und nicht in irgendwelche
Spezialbibliotheken.

Wer bestimmt denn, was "allgemein benötigt" wird?

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)

Hallo Peter

du bist etwas spät & OT, daher :


> Wenn Du es für "kindisch" hältst, dass jemand, der seinen Kunden gegenüber
> in der Pflicht steht, darauf achtet, dass deren Programme über einen
> vernünftigen Zeitraum weiterhin einsatzbereit bleiben sowie gepflegt und
> gewartet werden können, dann zeugt das nicht gerade von Professionalität.
> Ich weiss nicht, ob Du schon mal mit einem Kunden einen Vertrag über die
> Erstellung einer Software erstellt hast, aber Deine Statements hier lassen
> mich vermuten, dass Du noch nicht mit solchen Aufgaben betraut warst.


Zum 'Produkt' VB6 hat Microsoft auch immer den Life-Cycle
und die Strategie zum Wechsel auf .NET seit ~2001 klar kommuniziert.

Wenn du deinen Kunden mehr/längeren Support versprichst als Microsoft zu VB6,
dann ist dies schon dein eigenes Problem.
Microsoft hat dir nie einen Vertrag gegeben, dass VB6 unendlich haltbar ist.
Entscheidende Tatsachen sind da:
- die Upgrade-Alternative ist VB.NET

- VB6 (IDE & Runtime) läuft noch lange auf aktuellen PCs / Windows-OS,
nur der Support kostet jetzt halt etwas.


Abgesehen davon war/ist VB6 kein 'allgemeiner' Industrie/IT/ISO/ECMA - Standard
wie etwa C++, java, oder natürlich C#.
Daher ist u.U. immer mit zB einer etwas kürzeren 'Lebenszeit' zu rechnen.




>> 4.) die My-Krücke ist mit den VB6-Fn Kompat.-Krücken vergleichbar;
>> Noch fataler, das Problem hat sich dadurch bereits verdreifacht!...
> Welches Problem denn?
> Wenn ich es recht verstehe, hast nur Du damit ein Problem.

lies bitte nochmals:
Blog von Paul Vick, Microsoft VB.NET-Architekt :

http://www.panopticoncentral.net/arc...04/23/991.aspx

"But it has a NOT SO GOOD side.
It means VB.Net programmers will be learning and using a ...
*different* object model for many tasks"