generische Klassen



  • Hier ist eine Seite zu dem Thema und ein Prototyp zum Experimentieren.



  • 2008? Longhorn? 😉

    C# 2.0 kommt mit VS Whidbey, genau wie die neue Version der CLR. (inc BCL). Das
    wird laut Roadmap 2004 sein, also nicht mehr in ganz so ferner Zukunft. Wenn ich uptodate bin, kommt zusammen mit Longhorn VS Orcas was sicher noch eine ganze Weile dauern wird. Vielleicht nicht mehr 2005 .. wie hier bereits schon erwähnt. Aber die neue Sprachfeatures usw. sind im Whidbey Release. (VS 2004?!)
    Es gab einige sehr interessante Vorträge auf der PDC dazu. Die neuen Spracherweiterung(C#) sind bereits vor einem Jahr bei der ECMA eingereicht worden und funktionieren schon seit langer Zeit. Wer das Glück hat die Preview Version von der PDC zu haben kann bereits alle Features ausprobieren. (generics,anonymouse methods,iteratoren,partial types *hust) Ansonsten gibt es für die SSCLI Version der CLR die Generic Erweiterung Gyro (schon seit ~2 Jahren) die als Basis/Vorlage für die Generics in Whidbey dient.

    (den Link zu Gyro hat Dominic ja bereits gepostet).

    zur PDC findet man alles auf der PDC Site. (Fast alle Präsentation+Audio.. sehr emp. die von Hejlsberg, dem Chef Architekten von C#)

    Und Java 1.5 ist ja auch noch nicht da und kommt bestimmt nicht mehr dieses Jahr. Hehe. Ansonst schließe ich mich der Meinung an das Java 1.5 und C# 2.0 in etwa auf dem gleichen Niveau liegen. (nunja wer die mächtigeren Generics hat läßt sich ja nicht abstreiten 😃 )

    Der Meinung das .net "Beta" sein soll,finde ich doch recht falsch. Zumal zu .net ja viel mehr zählt als nur die Sprache C#. Die .net Platform ist neuer als die Java Platform und hat ihr sicher manche Dinge nachempfunden aber vorallem auch verbessert. Und das merkt man schon in einigen Bereichen wo Java 1.5 versucht alte Fehler auszubügeln(keine kovarianten Rückgabewerte) und teilweise ja auch wieder kräftig von .net (von der Sprache C#) kopiert. (enumerations,boxing,metadaten usw.) Zumal auch in der .net BCL Dinge wie Exceptionhierachie(die von Java is nur schlecht) oder Multithreading(in 1.5 gibts eine neue Threadlib aber das Problem das jedes Objekt ein Monitor ist bleibt.. *urgs) einfach besser sind.
    Achja ich will jetzt kein Sprachflamewar anfangen .. nur klarmachen das ".net" sicher seit langem nicht mehr "beta" ist 😃



  • Ich glaube, du hast Shade falsch verstanden. IMHO wollte Shade mit dem "Beta" sagen, dass das .NET-Framework mit Longhorn deutlich interessanter wird (wegen höherer Integration, höherer Verfügbarkeit,...). Insofern kann man das heutige .NET als Testplattform ansehen. Für viele wird es sich erst ab Longhorn lohnen, .NET als Grundlage für Projekte zu wählen. Das war also kein "technisches" Beta, sondern eher ein "wirtschaftliches" Beta.

    So habe ich es zumindest verstanden.



  • Ok. So kann man das auch sehen. Ich hab nur in die Richtung "Technik" argumentiert weil so Buzzwords wie Generics oder Java 1.5 gefallen sind. Das die .net Platform mit Longhorn sicher noch interessanter wird sehe ich genauso.

    Gegen "wirtschaftliches" Beta hätte ich auch was einzuwenden(seit kurzem 😉 ). Die .net Platform ist ja nun nicht mehr so neu und es gibt durchaus einige Enterprise Scale Produkte die zurzeit mit ihr entwickelt werden/bzw. für sie. Natürlich noch nicht soviel wie mit der Java Platform aber das ändert sich, denke ich im kommenden bzw. darauffolgenden Jahr und könnte sich dann bei einem Gleichgewicht einpeggeln.

    PS: Sorry für die ganzen Anglismen 😃



  • dynamix schrieb:

    Und Java 1.5 ist ja auch noch nicht da und kommt bestimmt nicht mehr dieses Jahr. Hehe.

    Naja, wenigstens für die Alpha-Version hat es gereicht, die komischerweise schon ein "Beta" und kein "Alpha" im Namen hat.

    http://www.heise.de/newsticker/data/boi-24.12.03-000/



  • dynamix schrieb:

    Natürlich noch nicht soviel wie mit der Java Platform aber das ändert sich, denke ich im kommenden bzw. darauffolgenden Jahr und könnte sich dann bei einem Gleichgewicht einpeggeln.

    Warum sollte eine Firma von Java auf .NET umsteigen?
    Welchen Sinn hätte dies?

    Bei 'neueinsteigern' die vor der Wahl Java oder .NET stehen kann .NET durchaus punkten - aber es gibt für Java momentan einfach ein größeres Angebot. Und viele Firmen verwenden .NET ersteinmal Testweise.

    Mit Java 1.5 legt Sun ja ordentlich was vor. Während .NET bis Longhorn stell stehen wird. Da geht sich sogar noch ein Java 1.6 aus...

    Sicher fangen Firmen an .NET zu nutzen - .NET ist ja nicht schlecht, und es sit sicher nicht verkehrt vor dem Longhorn release sich mit der .NET Architektur vertraut zu machen. Allerdings ist auch noch nicht klar wie stark .NET geändert wird.

    Also bei 'Neueinsteiger' kann .NET durchaus punkten, aber wenn die Firma bereits Java verwendet, wäre ein Umstieg irgendwie eine Verschwendung...



  • Shade Of Mine schrieb:

    Bei 'neueinsteigern' die vor der Wahl Java oder .NET stehen kann .NET durchaus punkten - aber es gibt für Java momentan einfach ein größeres Angebot. Und viele Firmen verwenden .NET ersteinmal Testweise.

    Sehe ich ja nicht unbedingt anderst. 😉 Bestehende Projekt sollte man nicht migrieren, das lohnte sich in fast allen Fällen nicht. Bei neuen Projekten ist die .net Platform sicher eine ernsthafte Alternative. Einen guten Vergleich der beiden Platformen J2EE und .Net finden man zB auf der JavaWorld Homepage (sicher keine pro-MS Site ;))

    Shade Of Mine schrieb:

    Mit Java 1.5 legt Sun ja ordentlich was vor. Während .NET bis Longhorn stell stehen wird. Da geht sich sogar noch ein Java 1.6 aus...

    Eben nicht ...

    dynamix schrieb:

    C# 2.0 kommt mit VS Whidbey, genau wie die neue Version der CLR. (inc BCL). Das wird laut Roadmap 2004 sein, also nicht mehr in ganz so ferner Zukunft.

    .. wohl überlesen was? 😉 Wird wohl nicht viel Zeit zwischen Java 1.5 und dem .net Framework 1.2(2.0?!) liegen. Siehe dazu aktuelle Roadmap. Dort findest auch was alles dazugehört.

    Btw: das Framework inc. C# 2.0 gibts auch bereits als Alpha. (PDC Release)



  • Mich würden Diskussionen über die neuen Features in der nächsten C#-Version interessieren. In welchem Forum wird man da fündig?



  • Es gab einige Threads in der Newsgroup microsoft.public.dotnet.languages.csharp aber die wesentlich interesanteren findest du in den privaten Newsgroups zum neuen Framework/C#2.0. (Solltest du Zugriff haben)

    Für eine Liste der Features kannst du in die Spezifikation schauen. Die findet man auf der offiziellen CSharp Seite

    Diskussionen findest du sonst in den einschlägigen Sites&Foren(gotdotnet,codeproject usw.) Wobei man da schon suchen muß und die Qualität nicht so toll ist. Muss mal abklappern hab leider keinen konkreten Link.

    Andere wüsste ich jetzt nicht. Vielleicht kann da wer anders noch einen guten Tip geben.



  • Hab ich was falsch verstanden? Die generischen Erweiterungen beider Sprachen sind doch nur eine Tippersparnis, damit man nicht mehr explizit casten muss. Generische Programmierung, wie in C++ oder Sather oder sonst wo lässt sich damit doch nicht betreiben. Klärt mich bitte auf, falls ich da was missverstanden habe.



  • In Java bieten die Generics IMHO tatsächlich nur 2 Dinge:

    1. Tippersparnis
    2. Typsicherheit

    Das liegt daran, dass in Java jede Klasse von Object abgeleitet ist und die Generics deshalb garnicht so nötig sind. Leider sind die Generics in Java nicht direkt mit primitiven Datentypen vereinbar, das geht nur über die Wrapper-Klassen.



  • Die Typsicherheit ist aber eine gute Sache. Ich finde das Containerkonzept von Java und C# etwas gewöhnungsbedürftig.

    Ich finde es z.B. verrückt, daß mir der Compiler verweigert einen int + uint zu rechnen, aber ich kann in einen Array-Container fröhlich abwechselnd Objekte vom Typ string und vom Typ Eigenbau reinstopfen - und wundere mich dann beim Durchlauf, warum bei jedem zweiten Objekt eine Exception fällt.

    Bei C++ ist das durch die Templates besser gelöst - in eine list<string> passen nur string-Objekte rein, und eine Polymorphie im Container gibt's nur, wenn ICH SELBST für die eingefütterten Objekte eine entsprechende Klassenhierarchie festgelegt habe.

    Mir erscheint das bisherige Vorgehen bei Java und C# sehr inkonsequent, bei den arithmetischen Ausdrücken so eine harte Typsicherheit zu fordern, aber beim ganz wesentlichen Bestandteil der vorhandenen Container darf man eigentlich alles machen, so ein Container frisst jede Instanz. Und die offizielle Empfehlung um das zu sichern lautet, daß man sich Wrapper um die Container bauen soll/muß.

    Insofern ist der Punkt "Typsicherheit" in meinen Augen ein recht großer Zugewinn.



  • Naja, mag sein, dass die Typsicherheit wirklich etwas bringt. Ich habe ja auch nichts gegen die Generics, nur hatte ich bisher keine Probleme damit, dass ich falsche Objekte oder so in eine Liste gesteckt habe, obwohl ich keine Wrapper gebaut hatte. Deshalb empfinde ich diesen Vorteil nicht als so stark.

    Aber der Umbau zu Generics geht auf jeden Fall recht flott. Ich habe mein aktuelles Javaprojekt (182 Klassen) in wenigen Stunden so ziemlich komplett auf Generics umgerüstet.

    Ich bin eigentlich deshalb von den Generics etwas enttäuscht, weil sie halt nicht direkt mit primitiven Datentypen funktionieren. Das hätte ich gut gebrauchen können. Naja, aber mit Java 1.5 kommt schon ne ganze Menge, was ich gut gebrauchen kann. 🙂



  • Gregor schrieb:

    Naja, mag sein, dass die Typsicherheit wirklich etwas bringt. Ich habe ja auch nichts gegen die Generics, nur hatte ich bisher keine Probleme damit, dass ich falsche Objekte oder so in eine Liste gesteckt habe, obwohl ich keine Wrapper gebaut hatte. Deshalb empfinde ich diesen Vorteil nicht als so stark.

    Naja, das liegt wohl an der persönlichen Wegrichtung, die man einschlägt.

    Ich komme aus der Richtung C++ und bin daher eher verblüfft, wie unsicher diese Container sind. Man kommt dann rasch an den Punkt wo man sagt "solche Programme sind aber nicht sehr sicher, wie kann man damit arbeiten".

    Kommt man aus der Richtung Java nach C++, wird einem ein ähnlicher Gedanke dann z.B. beim Thema Zeiger kommen.



  • dynamix schrieb:

    Die .net Platform ist ja nun nicht mehr so neu und es gibt durchaus einige Enterprise Scale Produkte die zurzeit mit ihr entwickelt werden/bzw. für sie. Natürlich noch nicht soviel wie mit der Java Platform aber das ändert sich, denke ich im kommenden bzw. darauffolgenden Jahr und könnte sich dann bei einem Gleichgewicht einpeggeln.

    Ich habe heute mal wieder bei Gulp in den "Trend Analyzer" geschaut und muss feststellen, dass es für .NET tatsächlich eine Zunahme an Projektanfragen zu geben scheint. Im letzten Monat gab es 3,9% Projektanfragen für .NET. Das ist zwar bei weitem noch nicht auf dem Niveau von Java (mehr als 15% im letzten Monat), aber es ist zumindest ein Wachstum zu registrieren.

    Was mich allerdings wundert ist, dass dieses Wachstum nur bei .NET zu beobachten ist, bei C#, ASP.NET, VB.NET ist davon nichts zu sehen. Es gab zum Beispiel im letzten Monat nur 0,2% Projektanfragen für C# (ASP.NET auch 0,2%, VB.NET nur 0,1%). Das ist seit etwa einem Jahr der tiefste Wert für C#. Insgesamt kann ich bei C# kein Wachstum feststellen.

    Ich frage mich deshalb, was man momentan überhaupt mit .NET macht. Welche .NET-Technologie wird momentan gebraucht?



  • Es könnte auch eine statistische Anomalie sein... daß Anfragen mit .NET und C# unter .NET eingeordnet werden, analog VB.NET, etc. Denn - macht das Sinn - Zunahme für .NET aber für keine Sprache? Irgendwie unlogisch. Wie wenn man sagt "Softwareentwicklung unter Windows", gibt aber keine Sprache dazu an. Da fehlt doch die Hälfte der Informationen.

    Soweit ich das bisher hören konnte, ist vor allem ASP.NET recht stark angenommen worden.



  • Naja, ich habe mir die .NET-Projektanfragen jetzt mal genauer angeguckt. Insgesamt hat der Gulp Roboter 27 Anfragen gefunden, in denen ".NET" vorkommt.

    Davon sind...

    ... 7 Anfragen vollkommen falsche Treffer. Hier kommt .NET beispielsweise so vor, dass man näheres bei einerEMail@Adresse**.net** erfahren kann. Auch folgendes wurde als .NET erkannt Netzwerktechnologie, NetBackup und Netinstall.

    ... 16 Anfragen nicht eindeutig für .NET-Projekte. Hier tritt das .NET nur als "Nice to have" neben vielen anderen Technologien, wie z.B. auch J2EE, oder in Texten, wie folgendem auf:

    Geforderte Kenntnisse

    - Kartenapplikationsentwicklung - Kartenpersonalisierung und -management - Hintergrundapplikationen insbesondere im Finanzdienstleistungssektor (Authorisierungssysteme, Customer Master Data, etc.) - Server und Client Technologie: WebServer, WebServices, Internet Browser - Mainframe Technologie - Erfahrungen mit Web-basierten Plattformen, J2EE, .NET mit den Anwendungsgebieten - kartenbasierte Zahlungssysteme insbesondere EMV und ePurse - Chipkartentechnologie, kontaktlos und kontaktbasiert - Global Platform Spezifikationen - IT Sicherheitsarchitekturen, Verschlüsselungsverfahren, Certificate Authority, Active Directory, Digitale Signatur, PKI, Firewalls, VPN, Authentifikationsverfahren Erfahrung in Akquisition und Proposalmanagement, Powerpoint, Englisch in Wort und Schrift. Bereitschaft zu Reisetätigkeit, hohe Belastbarkeit, Integrationsfähigkeit in andere Kulturkreise Sonstige Kenntnisse - Erfahrung in Akquisition und Proposalmanagement - Sehr gute MS Officekenntnisse insbesondere Powerpoint, Word und Project) - Gutes Englisch in Wort und Schrift - Basiskenntnisse in einer weiteren Fremdsprache (vorzugsweise Spanisch oder Französisch)

    ... 4 Anfragen eindeutig für .NET-Projekte.

    Wenn von den Projekten, die nicht eindeutig .NET-Projekte sind nur sehr wenige tatsächlich .NET-Projekte sind, dann würde das natürlich einiges erklären. Ich habe das Gefühl, dass einige das ".NET" in die Anfrage mit aufnehmen, weil es gerade "In" ist, aber nicht weil es tatsächlich benötigt wird.


Anmelden zum Antworten