none
Using internal .NET code. Or: Why are some useful classes marked as internal?

    Frage

  • Let's say you have to implement a Tokenizer. You could try to do it on your own, but this wouldn't be appropriate. Instead, you could use the MS.Internal.TokenizerHelper via reflection; but this may look like an ugly hack. Another example are classes marked as 'sealed' where there seems to be no reason for that. How do I work around those things?

    - I once saw a programmer using the decompiled code - or the one provided for reference - from the .NET libraries and changing this. (Is this legal?)

    Futhermore, I see no really way to work around such things... Why are they even marked as internal/sealed/etc.

    Montag, 25. November 2013 15:15

Alle Antworten

  • Hallo,

    da wir in einem deutschen Forum sind, die Antwort auf deutsch.

    Das viele Klassen nur intern zugänglich sind liegt daran, dass sie nur für einen bestimmten Zweck geschrieben wurden. Und ggf. nicht den Ansprüchen für eine allgemeine Verwendung genügen. Letzteres würde zum einen erhöhten Design- und Testaufwand bedeuten und zudem einen Support über die Laufzeit des Produkts (hier das .NET Framework).

    Was die rechtliche Seite angeht: Der Code des .NET Frameworks unterliegt dem Copyright. Und solange keine ausdrückliche Erlaubnis erteilt wird, ist die Verwendung nicht gestattet. Alles weitere bespreche mit einem Rechtsanwalt Deines Vertrauens ;)

    Was den Tokenizer selbst angeht: Das habe ich im Laufe der Jahre einige Male (mehr) in unterschiedlichen Sprachen und Umgebungen gemacht; das sollte man als Fingerübung betrachten ;) Zumal man heutzutage im Web genügend offene Quellen (mit passender Lizenz) finden kann, die man auf seine Bedürfnisse anpassen kann.

    Gruß Elmar

    Montag, 25. November 2013 16:02
  • Was soll ich denn dann von solchen Seiten halten:

    http://xstatic2.wordpress.com/2011/10/21/tip-improving-boolean-dependency-properties-performance/

    Hier wird quasi die BooleanBoxes Klasse vom Code her kopiert.


    Ich frage mich: Wo ist die Grenze zwischen kopieren des Codes und "abgucken" der Idee der Klassen etc. und ob alleiniges "abgucken" ebenfalls dem Copyright unterliegt...
    • Bearbeitet asdfgh0123 Dienstag, 26. November 2013 20:02
    Dienstag, 26. November 2013 19:56
  • Hi,

    das mit dem Copyright ist nicht ganz so einfach. Es hängt ja auch davon ab welche rechte dir der Inhaber einräumt.

    Als Beispiel kannst du die ja mal die Licencen von Mono anschauen, eine C# und .NET Varienate z.B. für Linux.

    MFG

    Björn

    Dienstag, 26. November 2013 20:28
  • Hallo,

    zum einen zieht das Argument, dass andere etwas auch tun, niemals - egal wobei!

    Vom rechtlichen Aspekt her kommt es darauf an, inwieweit es verfolgt wird. Wobei hier in Deutschland das Urheberrecht und in dem Zusammenhang die Schöpfungshöhe eine Rolle spielen.

    Wenn Du eine Software schreibst und sie vertreibst, solltest Du Dir darüber im Klaren sein, dass die Nutzung (selbst in Teilen) anderer geschützter Software, Rechtsansprüche zur Folge haben kann, die (viel) Geld kosten können.

    Da es sich dabei vorrangig um rechtliche Aspekte handelt, sind diese Foren nicht der geeignete Platz für solche Diskussionen - denn hier findest Du kaum einen darin bewanderten Juristen - und in deren Händen liegt das (leider ;)

    Gruß Elmar


    P.S.: Der Artikel für sich genommen ist mit Halbwahrheiten gespickt und argumentiert IMO einseitig. Siehe z. B. Abhängigkeitseigenschaften und Objekte
    • Bearbeitet Elmar Boye Dienstag, 26. November 2013 22:31 P,S.
    Dienstag, 26. November 2013 22:21
  • Ich versuche doch gar nicht damit zu argumentieren... Ich wollte nur darauf hinweisen.

    Aber: ich finde es schade, dass es da keine klaren Grenzen gibt. Wenn man mit dem Framework arbeitet, sollte man doch wissen, wo die Grenzen der Legalität liegen. Noch weiter rückt man in eine Grauzone, wenn man sich fragt, ob das Aufrufen von Methoden z.B. über Reflektion auch darunter fällt.

    Mittwoch, 27. November 2013 20:53
  • Hallo,

    die "Grenzen" legt der Gesetzgeber fest und interpretiert werden sie von den Gerichten. Das es (nicht nur) im Bereich der Software-Entwicklung durch das Urheber- und Patentrecht sehr kompliziert werden kann, steht auf einem anderen Blatt.

    Wie bereits im ersten Beitrag geschrieben, sind interne Klassen nicht für den allgemeinen Gebrauch gedacht. Unabhängig von einer "Legalität" gibt es keine Garantien. Die Code kann jederzeit verändert werden oder gar ganz entfallen.

    Einzig sicher ist es, den Code auf seinen eigenen Fundamenten aufzubauen. Und ausschließlich öffentliche dokumentierte Elemente zu nutzen.

    Findest Du Code, der für Dich nützlich sein könnte, so verstehe den Algorithmus und so kannst Du ihn Dir bei Bedarf selbst programmieren. (Und zum Thema Tokenizer findet man reichlich)

    Gruß Elmar

    Donnerstag, 28. November 2013 08:45
  • Was aber, wenn es gar keinen komplizierten Algorithmus gibt, sondern z.B. wie in der DoubleUtil Klasse, in der IsNaN-Methode nur die Idee, ein "Union" zu verwenden um den Wert zu konvertieren und dann zu prüfen?
    Donnerstag, 28. November 2013 15:29
  • Hallo,

    solche Klassen implementieren allgemeine Algorithmen, hier z. B.

    http://floating-point-gui.de/errors/comparison/

    und IsNaN[1] ist nichts Besonderes, wenn man den Aufbau von IEEE-754 FP kennt.

    Diese Algorithmen sollte man sich als Handwerkszeug aneignen, wenn man damit (intensiver) arbeitet. Und so in der Lage sein, solche Klassen selbst zu programmieren und dabei auf die eigenen Ansprüche anpassen.

    Man mag sich die .NET-Implementierung oder auch anderen Quellen (wie oben) als Vorlage nehmen. Sie direkt (via Reflection) zu verwenden, verbietet sich i. a. aus Performance Gründen, da dies i. a. bei höherwertigen, rechenintensiven Algorithmen zum Einsatz kommt.

    Gruß Elmar

    [1] Der Kommentar ist für neuere .NET Versionen nicht mehr zutreffend - mal offengelassen was die PBTCOMPILER Version ist -, denn in .NET 4.5.1 sieht IsNaN so aus:

    public unsafe static bool IsNaN(double d)
    {
    	return (*(long*)(&d) & 9223372036854775807L) > 9218868437227405312L;
    }
    (und dürfte mindestens genauso schnell, vermutlich sogar schneller sein ;)

    • Bearbeitet Elmar Boye Donnerstag, 28. November 2013 16:18 Format
    Donnerstag, 28. November 2013 16:17