16
Gibt es einen vernünftigen Grund, warum native properties nicht Teil von Java 7 sein wird?Warum wird es in Java 7 keine nativen Eigenschaften geben?
A
Antwort
15
Eigenschaften "richtig" in Java zu tun wird nicht einfach sein. Besonders die Arbeit von Rémi Forax war wertvoll, um herauszufinden, wie das aussehen könnte, und um eine Menge der "gotchas" aufzudecken, mit denen man sich befassen muss.
Inzwischen hat Java 7 schon zu lange gedauert. Die Debatte über die Schliessungen war eine riesige, kontroverse Ablenkung, die eine Menge Geisteskraft verschwendet, die dazu verwendet werden könnte, Merkmale (wie Eigenschaften) zu entwickeln, die einen breiten Unterstützungskonsens haben. Schließlich wurde die Entscheidung getroffen, wesentliche Änderungen der Modularisierung zu begrenzen (Project Jigsaw). Für die Sprache wird nur "Kleingeld" (unter Projektmünze) in Betracht gezogen.
JavaFX hat eine schöne Eigenschaftsunterstützung, daher versteht Sun den Wert von Eigenschaften und weiß, wie man sie implementiert. Nachdem Entwickler JavaFX-Eigenschaften verdorben haben, sind sie weniger geneigt, sich in Java auf eine halbfertige Implementierung zu einigen. Wenn es sich lohnt, sie zu tun, sind sie es wert, richtig gemacht zu werden.
+1
Für die weniger Informierten, könnten Sie kurz die Schwierigkeit bei der Implementierung von Eigenschaften in Java erklären? – Jason
3
- Nicht genug Zeit?
- Noch nicht richtig spezifiziert?
- Schwierig, Java wegen der Implementierung von Java hinzuzufügen?
- Als nicht wichtig genug gedeutet, dh andere Dinge wurden priorisiert?
18
Es gibt natürlich einige Gründe auf hoher Ebene, die sich auf den Zeitplan und die Ressourcen beziehen. Die Implementierung von Eigenschaften und das Verstehen aller Verzweigungen und Überschneidungen mit anderen Sprachfunktionen ist eine große Aufgabe, die der Größe verschiedener Java 5-Sprachänderungen ähnelt.
Aber ich glaube, der wahre Grund Sun nicht Eigenschaften ist die gleiche wie Verschlüsse drängt:
1) Es gibt keinen Konsens darüber, was die Umsetzung aussehen soll. Oder vielmehr, es gibt viele konkurrierende Alternativen und Menschen, die sich für Immobilien begeistern, sind sich über entscheidende Teile der Umsetzung nicht einig.
2) Vielleicht noch wichtiger ist, dass es einen signifikanten Mangel an Übereinstimmung darüber gibt, ob das Feature überhaupt gewünscht wird. Während viele Leute Eigenschaften haben wollen, gibt es auch viele Leute, die das nicht für notwendig oder nützlich halten (insbesondere glaube ich, dass serverseitige Leute Eigenschaften für ihr tägliches Leben als weniger wichtig ansehen als Programmierer).
Eigenschaften Geschichte hier:
+0
Interessant. Ich war mir der Kontroverse über Immobilien nicht bewusst, zumindest hat nicht die Art von flammenden Hass-Schließungen provoziert. Kannst du Links bereitstellen, um den Hintergrund von Vor- und Nachteilen zu verdeutlichen? Ich stimme zu, dass Eigenschaften serverseitig weniger wichtig sind und JavaFX die Anforderungen auf dem Client anspricht. – erickson
+1
Als eine serverseitige Person, Eigenschaften ist alles, was ich habe. – trunkc
+0
Ein Link zu älteren Immobilien-Diskussionen hinzugefügt. Persönlich bin ich stark ambivalent. Ich finde, dass die meisten Vorschläge mich nicht zu aufgeregt machen. Ich bin mir nicht sicher, ob Java in dieser Abteilung weit genug gehen kann, um wirklich wie Groovy oder Scala zu befriedigen. –
10
Jede beliebige Sache ist standardmäßig „nicht getan“, so kein besonderer Grund für etwas braucht nicht getan zu bleiben. Es ist vielmehr ein zwingender Grund notwendig, etwas von "nicht gemacht" zu "geplant" oder "getan" zu verschieben. Für dieses Sprachmerkmal ist noch kein ausreichend überzeugender Grund vorhanden.
5
Es gibt zwei weitere Gründe Eigenschaften in jeder Sprache zu vermeiden:
Eigenschaften sind nicht sehr objektorientiert. Wenn sie einfach zu schreiben sind, wird das Muster ermutigt, bei dem das Objekt nur seinen internen Zustand erfüllt und der Anrufer es manipuliert.Das Objekt sollte Methoden auf höherer Ebene bereitstellen und seine Interna privat halten. Wenn Sie das nächste Mal mühsam einen Getter implementieren, überlegen Sie, was der Aufrufer mit den Daten macht und ob Sie diese Funktionalität direkt bereitstellen können.
Eigenschaften fördern veränderlichen Zustand (durch Setter), die ein Programm weniger parallelisierbar macht. Wenn die Anzahl der Kerne steigt, sollten wir alle versuchen, unsere Objekte unveränderlich zu machen, um das gleichzeitige Denken zu vereinfachen. Wenn Sie das nächste Mal einen Setter mühsam implementieren, sollten Sie ihn entfernen und das Objekt unveränderlich machen.
+1
Ich Objekt _ "Eigenschaften sind nicht sehr objektorientiert" _. Und andere auch: _ "[" objects ", das sind Datenstrukturen, die Daten in Form von Feldern enthalten, die oft als Attribute bezeichnet werden, und Code in Form von Prozeduren, die oft als Methoden bezeichnet werden.] (Http://en.wikipedia.org/wiki/Object-oriented_programming)"._ Erzwingt, dass ein Benutzer eines (API/class /) Objekts die Hälfte dessen ignoriert, was er definitionsgemäß hat, ist zumindest nicht zu verstehen. Es ist sowohl unnatürlicher als auch aufgeblähter Code: 'person.name =" Nimoy ";' vs. 'person.setName (" Nimoy ");' und 'name = person.name;' vs. 'name = person.getName(); . ' –
+0
Ich schlage vor, den Ausdruck "nicht sehr objektorientiert" zu vermeiden (was an dieser Stelle fast bedeutungslos ist), aber beide Punkte beizubehalten (die sich auf gutes Design beziehen, schlicht und einfach). Ansonsten konzentrieren sich die Leser auf ihre eigene Definition von OOP und ignorieren, was hier wirklich gesagt wird. – tne
Messen Sie die Fähigkeiten einer Sprache nicht anhand der Anzahl ihrer Funktionen. Denken Sie an die Plattform, das Ökosystem, ... –
das war ein phänomenaler Kommentar Ivan. Ich lerne C#, und viele der Features, die mir fehlen, die Java nicht hat, schreien nicht, als ob sie bemerkenswert schwierigere Probleme lösen würden. Manche scheinen auch so zu sein, als könnten sie einem komplizierteren Code nachgeben, als ob mehrere Dinge von einer Methode über Outs zurückkehren würden. Oder die berüchtigte goto-Aussage. –