Laden...

Framework 2 obsoletes

Erstellt von Lexodus vor 17 Jahren Letzter Beitrag vor 17 Jahren 4.842 Views
L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren
Framework 2 obsoletes

Hallo zusammen

Ich hoffe dieser Thread wird nicht gelöscht, weil ich irgendwo meinen Unmut über Microsoft und das .NET Framework kund tue. Aber mich würde einfach interessieren was sich Microsoft bei sowas denkt (vielleicht weiss einer von euch etwas);

http://msdn2.microsoft.com/de-de/library/system.appdomainsetup.shadowcopyfiles(VS.80).aspx

Das ist doch einfach nur ein Witz, das sowas überhaupt in ne API kommt ist überhaupt n Witz.

Für alle die den Link nicht lesen wollen...

Ich muss hier einem Get/Set property den Wert "true" und "false" als string übergeben... und das ist deren Ernst.

Wenn Microsoft so weitermacht programmier ich auf der Insel. Dort wird wenigstens nicht jeder mist in die API aufgenommen.

Gruss

If you can't make it, fake it.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Das dazu passende Blog:

http://blogs.msdn.com/brada/archive/2005/11/17/494282.aspx

"API design hall of shame..."

Offizielles Begründung des MS-Entwickler-Teams: "Apparently the rationale for using string was that the underlying infrastructure uses strings rather than bools."

Lol.

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

omfg.

So geil, danke für den Link.

If you can't make it, fake it.

369 Beiträge seit 2006
vor 17 Jahren

Auch bei Microsoft arbeiten nur Menschen... genauso wirst du in jedem anderen Großprojekt (etwa auch Java) Mist finden. Aus Gründen der Abwärtskompatibilität lässt sich die von dir genannte Eigenschaft leider auch nicht ändern.

4.207 Beiträge seit 2003
vor 17 Jahren

Original von Kabelsalat
Auch bei Microsoft arbeiten nur Menschen...

So weit gebe ich Dir recht.

Original von Kabelsalat
genauso wirst du in jedem anderen Großprojekt (etwa auch Java) Mist finden.

Auch hier gebe ich Dir recht.

Original von Kabelsalat
Aus Gründen der Abwärtskompatibilität lässt sich die von dir genannte Eigenschaft leider auch nicht ändern.

Hä? Diesen Punkt verstehe ich nicht ... kannst Du das ein wenig genauer erläutern?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
8.746 Beiträge seit 2005
vor 17 Jahren

Aber eine Überladung mit bool wäre in 2.0 schon schön gewesen....

369 Beiträge seit 2006
vor 17 Jahren

// Geht bekanntermaßen nicht
public string ShadowCopyFiles { get; set; }
public bool ShadowCopyFiles { get; set; }

Einzige Lösung wäre eine zweite Eigenschaft mit anderem Namen (und die bestehende als obsolete kennzeichnen) - saubere Lösung, naja!?

4.207 Beiträge seit 2003
vor 17 Jahren

Dass das nicht geht, wusste ich noch nicht ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo zusammen,

man sollte eine Bibliothek daran messen, was sie alles leistet und nicht daran, dass es eine Eingenschaft gibt, die fragwürdig gestaltet ist.

herbivore

4.207 Beiträge seit 2003
vor 17 Jahren

Eine Bibliothek kann super sein vom Funktionsumfang her, und trotzdem schlecht gestaltet - die Kritik daran muss doch erlaubt sein, zumal wenn es etwas so offensichtliches ist?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

Ein Get Property in nen Get/Set Property umzuwandeln wird wohl nicht son Problem sein....

Sie haben es ja von "Get" Bool no Get/Set String geschafft....
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemappdomainclassshadowcopyfilestopic.asp

Und dann noch die Begründung;
"Weil interne Funktionen strings verwenden"

Ehrlich gesagt ist es mir egal was die intern machen, es hat mich auch nicht zu interessieren, von mir aus können sie intern an ihren strings ersticken. Dieser Mist hat in ner öffentlichen API aber nichts verloren.

Auf Deutsch, die sollen nen bool entgegen nehmen und ihn in ihrer Implementation auf nen string drehen und nicht wir.

Mit n bischen Pech, gibts wie früher n Deutsches VB.NET das "wahr" und "falsch" verwendet.... oh Gott ich hoffe nicht.

@Edit

kleine Missverständis, hab AppDomainSetup und AppDomain vermischt. Das Property war früher schon so da. War auf der AppDomain class ein wenig anders.
true und false als string mitzugeben find ich aber nachwievor shamig

If you can't make it, fake it.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Golo,

Eine Bibliothek kann super sein vom Funktionsumfang her, und trotzdem schlecht gestaltet

Ist die das? Im Großen und Ganzen m.E. nicht. Mein Punkt war eher, dass es bei mehreren zehntausend Methoden/Eigenschaften vermutlich immer gelingt, eine zu finden, an der man was kritisieren kann.

die Kritik daran muss doch erlaubt sein, zumal wenn es etwas so offensichtliches ist?

Kritik ist erlaubt, das begründete Zurückweisen derselben m.E. aber auch. 🙂

herbivore

6.862 Beiträge seit 2003
vor 17 Jahren

Also ich bin da Herbivores Meinung. In einer Klassenbibliothek wo es zigtausend Klassen/Funktionen/Properties gibt, gibts ein paar Fehldesigns und deshalb soll die Klassenbibliothek nicht gut sein? Ich find sogar dass die Klassenbiliothek im großen recht konsistent wirkt. Meine die Klassenbibliothek wird nicht nur von 2-3 Entwicklern geschrieben worden sein, da sind viele Leute dran beteilgt und trotzdem wirkt sie wie aus einem Guss, des find ich schon bemerkenswert.

Baka wa shinanakya naoranai.

Mein XING Profil.

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

Also grundsätzlich muss ich sagen, versteh ich hier auch die Gegenargumente...

Menschen machen Fehler... is richtig....

Finde aber es kommt darauf an was für n Fehler.

Mit dem Framework ist alles so toll typisiert und objektorientiert klasse. Konzept schon langa von der Java Welt verstanden jetzt auch von Microsoft.

Umdenken bitte weg von komischer VB-Programmierdenkweise zu richtiger objektorientiert heit. Und dann kommt sowas, dass geht mir einfach nicht in den Kopf.

Das ist nicht son einfacher/kleiner API design fehler mir kommt es so vor als ob nicht mal die Microsoft-Entwickler den Umstieg von VB auf ne richtig objektorientierte Sprache geschaft haben.

If you can't make it, fake it.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Lexodus, hallo zusammen,

kennst ihr das nicht, dass ihr was programmiert, euch das später anguckt und euch fragt, warum ihr das so (schrottig) gemacht habt? Freut euch doch lieber, dass bei Microsoft auch nur mit Wasser gekocht wird. Wäre ja schlimm, wenn alle anderen perfekt wären und nur man selber Fehler machen würde.

Sicher sind die Qualitätsmaßstäbe bei einer so wichtigen Bibliothek wie dem .NET Framework höher, als wenn man eben ein Programm für sich selbst schreibt. Aber wie ich schon geschrieben habe, werden die Qualitätsmaßstäbe m.E. bis auf Ausnahmen ja auch eingehalten.

Davon abgesehen: was soll mit der Kritik erreicht werden?

herbivore

1.665 Beiträge seit 2006
vor 17 Jahren

Wir können damit nix erreichen, uns nur darüber unterhalten und sind dadurch nicht wirklich schlauer. Am Besten selber direkt an Microsoft wenden oder es akzeptieren, da ja eine Begründung abgegeben wurde. Auch wenn diese etwas schmeichelhaft ist 😁

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

Ziel der Kritik;

  • Frust ablassen
  • Sehen ob die Kritik stimmt oder nicht.
  • Sehen wie frustriert andere damit sind --> Frust ist dann komplett abgelassen.
  • Lernen das Microsoftmenschen auch Fehler machen.
  • Ab diesem Zeitpunkt kehrt der Humor zurück und die Freude am Framwork😉

Das ist das Ziel. Und du Herbivore/Ihr habt mir geholfen 😉
Ich bin wieder im Jin/Jang.

Der hall of shame link hat mich schon ziemlich aufgebaut ...

If you can't make it, fake it.

6.862 Beiträge seit 2003
vor 17 Jahren

Original von Lexodus
Das ist nicht son einfacher/kleiner API design fehler ...

Es ist nur ein kleiner Designfehler der API! Es ist** ein** Property aus Tausenden das man wahrscheinlich der Bequemlichkeit halber als String gelassen hat und du fängst an am Programmierverständnis der Entwickler zu zweifeln?

Das zeugt für mich eher für wenig Weitsicht. Bei solch großen Projekten kommen noch ganz andere Faktoren dazu die die Qualität des Produkts beeinflussen. Auch muss man davon ausgehen das die API ja nem Review Prozess während der Entwicklung unterlag von daher glaub ich schon das es nen Grund gab das so zu lassen, auch wenn er für uns vielleicht nicht verständlich sein mag.

Baka wa shinanakya naoranai.

Mein XING Profil.

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

Sorry vielleicht hab ich mich falsch ausgedrückt.

Der Fehler an und für sich, ist ganz gaaaanz klein.
In meinem Programmierverständis müssten alle Alarmglocken klingeln und jedem die Haar zu berge stehen wenn einer mit nem Vorschlag kommt nen bool als string zu übergeben... daher find ich es ja so extrem.

Gibt viel "gröbere" Fehler im Framework, die sind aber nicht so schlimm von der Denkweise her.

If you can't make it, fake it.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von talla
Es ist nur ein kleiner Designfehler der API!

Aber was für einer! 😉

Auf jeden Fall so anfängerhaft, dass man mit Freude drüber lästern kann. Ob es nun einer unter 10, 100 oder einer Million ist, spielt keine Rolle. Der Fehler bleibt gleich grausam. Man kann allenfalls Verständnis für die Qualitätskontrolle bei MS aufbringen, die den Fehler übersehen hat, nicht aber für den Entwickler bzw. für das Team, der diese Schnittstelle geschrieben hat (das ist ja mit Vorsatz geschehen). Ob das Framework insgesamt gut oder schlecht ist, kann man nicht an der Kritik an einer Schnittstelle festmachen. Ebensowenig kann aber die Kritik durch die (gute) Gesamtqualität des Frameworks wegdiskutiert werden.

Müll bleibt Müll, und das IST Müll.

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

Original von svenson

Original von talla
Es ist nur ein kleiner Designfehler der API!

Aber was für einer! 😉

Auf jeden Fall so anfängerhaft, dass man mit Freude drüber lästern kann. Ob es nun einer unter 10, 100 oder einer Million ist, spielt keine Rolle. Der Fehler bleibt gleich grausam. Man kann allenfalls Verständnis für die Qualitätskontrolle bei MS aufbringen, die den Fehler übersehen hat, nicht aber für den Entwickler bzw. für das Team, der diese Schnittstelle geschrieben hat (das ist ja mit Vorsatz geschehen). Ob das Framework insgesamt gut oder schlecht ist, kann man nicht an der Kritik an einer Schnittstelle festmachen. Ebensowenig kann aber die Kritik durch die (gute) Gesamtqualität des Frameworks wegdiskutiert werden.

Müll bleibt Müll, und das IST Müll.

Möchte mich dem hier anschliessen 🙂

If you can't make it, fake it.

369 Beiträge seit 2006
vor 17 Jahren

Original von Golo
Dass das nicht geht, wusste ich noch nicht ...

Theoretisch müsste es bei einem reinen Setter gehen (probiert habe ich es aber noch nie) - in Kombination mit einem Getter kann es aber nicht funktionieren: Wenn man sich eine generierte Assembly mit Reflector anschaut (oder den J# Code in der Doku) sieht man, dass intern folgendes generiert wird:


public void set_ShadowCopyFiles(string value)
{
     // ...
}

public string get_ShadowCopyFiles()
{
     // ...
}

Nun darf beim Überladen einer Methode der Rückgabewert nicht geändert werden und daher kann get_ShadowCopyFiles() nicht mit einer alternativen Funktion mit Rückgabewert bool überladen werden.

Alternativ kann man auch folgendermaßen argumentieren:


// Angenommen folgendes ginge...
public string ShadowCopyFiles { get; set; }
public bool ShadowCopyFiles { get; set; }

// ... würde folgendes noch funktionieren
ShadowCopyFiles = "NurEinTest";
ShadowCopyFiles = true;

// ... nun gibt es aber Konflikte (bzw. wenn es ginge würde es sich um schlechtes Sprachdesign handeln, da der Compilerbau unnötig erschwert würde)
string testString = ShadowCopyFiles;
bool testBool = ShadowCopyFiles;

1.665 Beiträge seit 2006
vor 17 Jahren

Meiner Meinung nach sind Klassen, die als Serializable markiert sind, aber keinen Default Ctor haben, noch schlimmere und auffälligere Merkmale, aber keiner heult deswegen rum.
Einfach akzeptieren und einen Verbesserungsvorschlag einreichen. Klappt dies nicht, starte doch eine Anti-.NET Kampagne 😉

369 Beiträge seit 2006
vor 17 Jahren

Diese sollten aber bloß sehr sehr selten vorkommen, da bereits FXCop bzw. die CodeAnalysis-Komponente aus dem Visual Studio Team System dies kritisiert.

L
Lexodus Themenstarter:in
254 Beiträge seit 2005
vor 17 Jahren

@Kabelsalat

100% richtig, eine Methode darf sich nicht nur in ihrem Rückgabewert unterscheiden.

Dieses Property hätten sie aber schlicht und einfach als obsolete markieren können und was anders nehmen.

AppDomain.SetShadowCopyFiles() obsoloete, genau so wie AppDomainSetup.ShadowCopyFiles.

Und was richtiges nehmen.

So grundsätzlich markiert man Sachen als obsolote, weil man früher nen Fehler gemacht hat, oder das design verbessert werden konnte.

Wenn das "richtige" aber auch wieder was ist das vom Design her grottig ist dann komm ich ins grübeln...

If you can't make it, fake it.

T
512 Beiträge seit 2006
vor 17 Jahren

Ihr solltet mal sehen, was für ein Murx alles in euren Prozessoren steckt. Da ist das wirklich wie ein Fleck auf der Tischdecke im Vergleich zu einem brennenden Tisch.

@JunkyXL
Serialisierbare Klassen brauchen auch keinen Default-Konstruktor. Es gibt da sogar einen speziellen Konstruktor (also bestimmte Parameter), der aufgerufen wird, wenn etwas serialisiert wird. Und den kann man sogar protected/private machen und er wird trotzdem benutzt.

Du willst wahrscheinlich auf Xml-Serialisierung hinaus. Dort braucht man zwingend einen Konstruktor ohne Parameter. Das hat aber mit dem SerializableAttribut nix zu tun.

e.f.q.

Aus Falschem folgt Beliebiges

1.665 Beiträge seit 2006
vor 17 Jahren

Original von Traumzauberbaum
Ihr solltet mal sehen, was für ein Murx alles in euren Prozessoren steckt.

*Interessiert tut*

Du willst wahrscheinlich auf Xml-Serialisierung hinaus.

Si.

Dort braucht man zwingend einen Konstruktor ohne Parameter. Das hat aber mit dem SerializableAttribut nix zu tun.

Achso, wieder was gelernt.

T
512 Beiträge seit 2006
vor 17 Jahren

Oh da muss man sehr weit ausholen. Vieleicht reicht es ja zu sagen, dass in deinem CPU immernoch Stücke von vor 20 Jahren drin sind. Damals hat man noch so designed, dass der Assembler Code besser lesbar und kürzer ist. Das heißt da stecken Befehle drin, die im Assembler Code gleich mehrere Aufgaben auf einmal lösen. Und heutzutage sind das Altlasten, die wegen der Rückwärtskompatibilität immernoch mitgeschleppt werden müssen und den Prozessor-Architekten große Probleme bereiten.

Man hat im Prinzip mit einem Dreimannzelt begonnen und nach und nach Etagen draufgebaut, bis zum 50-stöckigen Hochhaus von heute, dass immernoch auf dem Fundament des Zeltes steht.

e.f.q.

Aus Falschem folgt Beliebiges

4.506 Beiträge seit 2004
vor 17 Jahren

Hallo zusammen,

vielleicht ist es Unsinn, was ich schreibe, aber ich habe mir nicht bis ins kleinste Detail alle Beiträge durchgelesen.

Wenn dementsprechend Funktionen drunter liegen, die nur strings akzeptieren, dann hätte ich das im .NET Framework folgendermaßen gelöst:


public bool ShadowCopyFiles
{
   get
   {
       return bool.Parse(base.ShadowCopyFiles);
   }

   set
   {
       base.ShadowCopyFiles = Convert.ToString(value); 
   }
}

Und die Sache wäre gekapselt und verschwunden, oder liege ich da jetzt verkehrt?
Um das ganze dann noch wirklich typsicher zu machen, kann man beim Getter auch ein TryParse noch dazunehmen...

Also egal was drunter ist, die Schnittstelle ist falsch implementiert, meiner Meinung nach.

Gruß
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

B
1.529 Beiträge seit 2006
vor 17 Jahren

Oh da muss man sehr weit ausholen. Vieleicht reicht es ja zu sagen, dass in deinem CPU immernoch Stücke von vor 20 Jahren drin sind. Damals hat man noch so designed, dass der Assembler Code besser lesbar und kürzer ist. Das heißt da stecken Befehle drin, die im Assembler Code gleich mehrere Aufgaben auf einmal lösen. Und heutzutage sind das Altlasten, die wegen der Rückwärtskompatibilität immernoch mitgeschleppt werden müssen und den Prozessor-Architekten große Probleme bereiten.

Man hat im Prinzip mit einem Dreimannzelt begonnen und nach und nach Etagen draufgebaut, bis zum 50-stöckigen Hochhaus von heute, dass immernoch auf dem Fundament des Zeltes steht.

Ist zwar alles richtig (dank AMD und MS wollte der Markt halt weiter x86).
Fairerweise muss man jedoch zugeben, dass der Prozessor während des Programmierens (weil es ja auch meist ein anderer ist) nicht einfach sagen kann: "Du, äh, nimm mal was anderes, das hier ist echt großer Müll, da gibt es was neueres, besseres."