Ahoi,

für die, die was zu Swift Steel loswerden wollen, gibt's hier den passenden Thread Tobt euch aus!

Grüße,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

(hey, nicht alle auf einmal... *g*)

~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich glaube, das Problem warum hier so wenig kommt ist, dass der Projektthread (oder beschränkt sich das auf mich?) bisher noch sehr abstract wirkt. Es ist vieles irgendwie gesagt, aber wenig konkretisiert
Ich wünsch mir zum Beispiel ausführlichere Erklärungen zu Scala, irgendwie kann ich mit der Scala-HP nämlich nicht viel anfangen...

Und sich zur Spielidee zu äußern fällt auch etwas schwer, weil dazu ja auch noch nicht endlos viel gesagt ist

Wie hat waran (ich behaupte, er war es) es mal schön formuliert: "Screenshot/Picture or it doesn't exist".
Wir wissen nichts über deine genaue Spielidee.
Wir wissen nichts über das Aussehen (Screenshots!!!).
Wir wissen nicht, was du machst.

Du machst halt was mit Fancy-Scala. Und nun mit Fancy-Scala 2.8 und hast deshalb ein wenig entrümpelt und optimiert. Aber wenn man nichts sieht, ist es trotzdem richtig von zoiX formuliert: abstrakt.

Andere Projektthreads bieten Videos, Bilder, Testversionen oder Seitenfüllende Erklärungen, Beschreibungen und Ziele. SaschaWillems und LittleDave schreiben z.B. immer eine ganze Menge interessanten Kram (neben den geilen Screenshots ^^).

Probier Yang ein bisschen besser medial aufzubereiten und die Kommentare kommen von alleine. So bleibt das hier eher ein Metakommentar: Ein Kommentar über Kommentare bzw. ein Kommentar über die Zugriffskurve, die dein Projekt da hat, die aber auch nichts über dein Projekt aussagt. ^^

LG Ziz

PS: Achso, was auch fehlt, wie mir immer wieder bei mir berichtet wird, ist Tanzmattenunterstützung!

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Yay, Feedback! ^.^

Hmm okay. Ich bin halt imho mehr auf die Dinge eingegangen, die für DGL-Projekte eher unüblich sind. Also so Sachen wie Unit-Tests, BDD, das Repository bei GitHub, und sowas. Die Spielidee hab' ich dabei etwas vernachlässigt, stimmt. Werd' ich korrigieren

Screenshots gibt's erstmal keine, da ich viel am Unterbau machen werde, bevor ich anfange, etwas zu rendern.
Man könnte jetzt argumentieren, dass ich ja vom Unterbau - vom Klassendesign - ja UML-Diagramme machen könnte. Klar könnte ich das, aber ich bin nicht soo der Fan von ausgewachsenen UML-Diagrammen für Hobbyprojekte Insofern wird das eher die Ausnahme sein, dass ich da Klassendiagramme hochlade.
Ich kann aber gerne bei interessanten Klassenkonstellationen (Ich nenn's mal so... ^^) ausführlicher drauf eingehen, warum ich die so gestaltet habe, falls das von Interesse ist. Dann auch mit dem ein oder anderen Klassendiagramm

Testversionen gibt's daher auch erstmal keine. Denn was nützt ne Testversion, wenn man nichts sieht... Denke die wenigsten von euch werden ganz fasziniert Yang herunterladen, nur um dann die Unit-Tests auszuführen

UUuund die Tanzmattenunterstützung: Ob du's glaubst oder nicht, an die hab' ich gedacht Werde das auch noch mal expliziter in den Projektethread hineinschreiben.

Wg. Scala: Das ist schwer, was dazu zu sagen, weil ich nicht weiß, welchen Hintergrund derjenige hat, der sich das durchliest. Daher müsste ich alles abdecken und das wär' dann etwas arg viel . Am ehesten lässt sich da vielleicht noch auf den Wikipedia-Artikel verweisen. Ich änder aber mal den Link auf die Scala-Website. Da gibt es nämlich einen ganz guten Überblick darüber, was Scala so kann. Die deutsche Übersetzung dessen ist übrigens in dem Wikipedia-Artikel

Grüße,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Die Themable Widget Library hab ich seit dem DGL Treffen auch noch in nem Tab offen.

Ich selber hab sie noch nicht ausprobiert. Hast du mal mit dem Schöpfer gesprochen? Ist das Projekt noch aktiv?

Hast du mal Tests damit gemacht? Also wie schwer ist es damit eine GUI zu bauen? Muss man händisch Coden, oder gibt es einen Editor.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nö, hab nicht mit dem Entwickler gesprochen ^^
Warum sollte denn die TWL nicht weiterentwickelt werden? O.o
Hast du mal nen Blick ins Repository geworfen? Letztes Update war am 15. Februar 2010. Also vor 5 Tagen... Auf mich macht das einen relativ lebendigen Eindruck

Tests hab ich noch nicht gemacht, aber ich würde mal stark davon ausgehen, dass es keinen GUI-Editor dafür gibt.
Ist aber auch nicht schlimm, ich hab nämlich kein Problem damit, meine GUI händisch (aber deklarativ) (siehe die *.dfm, die Delphi produziert) zu schreiben. Und mit ner eigenen Scala DSL ist auch das nicht weiter wild.
Daran soll's wirklich nicht scheitern

Grüße,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich würde gerne mal wissen, ob du irgendwelche Quellen hast, wo man mehr über den sinnvollen Einsatz von immutable objects lesen kann. Soweit ich weiß ist es das, was man in java als finale Attribute hat. Die benutze ich allerdings so gut wie nie und kann mir irgendwie schwer vorstellen, nahezu alles in einem Projekt final zu machen. Darüber würde ich gerne mehr erfahren.

Bei uns auf Arbeit haben wir ein Codestyle tool, welches z.B. aufschreit, wenn man in inline Klassen (z.B. Action listenern) auf Variablen von außerhalb zugreift die nicht final sind. (Ich glaub so war das.) Also falls dich die verwendung von Final interessiert hat. Falls das nicht die Frage war, einfach ignorieren.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das Prinzip der Immutability ist in funktionalen Sprachen sehr weit verbreitet - es sollte sich da also prinzipiell bei den meisten Quellen über funktionale Sprachen was finden lassen. Meine Quelle dafür ist hauptsächlich schlicht und ergreifend das Standardwerk für Scala, zu finden bei der Bücherliste auf scala-lang.org. Das Buch, worauf ich mich beziehe, ist "Programming in Scala" u.A. von Martin Odersky, dem Vater von Scala. Dort werden u.A. die Vorzüge von immutable Objects aufgeführt und auch konkret gezeigt, wie man die in Scala effektiv verwenden kann.

In Effective Java von Joshua Bloch steht auch einiges zu Immutability drin und das Buch sollte man als Java-Entwickler ja sowieso sein Eigen nennen bzw. zumindest irgendwie Zugang dazu haben

Was die final fields in Java angeht: Da hab' ich erst neulich einen kleinen Vortrag drüber gehalten Hier die Kurzfassung (stammt übrigens aus Effective Java):

Es reicht nicht, alle Felder in einer Klasse final zu machen, damit sie immutable ist. Das ist zwar schonmal ein sehr guter Anfang und wichtiger Schritt, aber eben noch nicht ganz ausreichend. Dazu ein Codebeispiel:

Sieht auf den ersten Blick immutable aus - ist es aber nicht:


Wenn man nun im Konstruktor von Date Kopien von den reingegebenen Parametern macht...:

steht man vor dem nächsten Problem: Während der Überprüfung der Parameter, die wir hier machen, kann ein anderer Thread immernoch start und end modifizieren. Das Problem ist bekannt als TOCTOU ("Time of creation - time of usage").

Lässt sich so verhindern:

Jetzt kommt der Code zum Überprüfen nach dem Kopieren der reingegebenen Parameter und bezieht sich nun auch auf die Kopien und nicht mehr die potentiell gefährlichen Parameter.

Doch das war noch nicht alles:

Wir haben auf das Date noch zugriff über die Accessor-Methoden. Auch das lässt sich leicht ändern:


Jetzt ist die Klasse wirklich sicher und komplett immutable.

Eine Spezialität gibt's aber noch zu erwähnen: Man könnte einwerfen, dass man statt dem Copy-Konstruktor auch Object.clone() hätte verwenden können.
Dagegen spricht aber:

• Object.clone() ist böse, gibt's vieeeeeele gute Grüne, es nicht einzusetzen. Die werd ich jetzt nicht wieder alle vorkauen
• clone muss nicht zwingend ein Date zurückliefern. Date ist leider nicht final und kann überschrieben werden. Wenn man nun die clone Methode überschreibt und sein eigenes Date zurückliefert, hat man wieder eine Lücke geschaffen, über die man potentiell was verändern kann

Alles klar?

Wäre Date im übrigen selbst immutable (hätte also kein setYear und sowas) und wäre es final, dann könnte man sich das Kopieren und den ganzen Mist sparen. Das ist mit ein Grund, warum man schauen sollte, möglichst alles immutable zu machen.


Soo... Bei Fragen zu immutability und sowas, einfach Fragen, ich erklär das gerne Bleib ich auch selber in der Übung ^^
Und so viel ist es auch gar nicht mit der Immutability, was anders ist. Eine der typischen, unveränderlichen Klassen verwendest du bestimmt auch täglich: String Ist ein ganz prominentes Beispiel und zeigt gut, dass Immutability nichts exotisches ist sondern was ganz alltägliches.

Grüße
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Vorrausgesetzt, du meinst mit "inline Klassen" innere, anonyme Klassen, so kannst du gar nicht auf äußere Variablen zugreifen, die nicht final sind (sonst könnte man Closures in Java machen).

Der folgende Code liefert einen Compile-time Error:


Wenn man sein Runnable aber als nicht-anonyme Klasse definiert, ihm also nen Namen gibt und es folglich außerhalb einer Methode steht, kann man immerhin auf non-final Fields der umgebenden Klasse zugreifen.

Grüße
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Hi,

kleine frage zu dem Immutable/Final kram:
Welchen genauen sinn macht es, ALLES so zu designen..?

Gut wenn irgendwann ein DAU herkommt und deinen Code nutzt mag das noch nachvollziehbar sein, aber diese ganze Copy-geschichte macht den Code nicht unbedingt performanter, und grade bei Spielen die schnell laufen sollen würde ich solche sachen versuchen zu vermeiden.

Oder gibt es einen ganz wichtigen Grund den ich grad nicht sehe, warum alles Immutable sein muß??

Aya

@Frase: Danke das war schonmal sehr aufschlussreich.

@Aya: Das ist auch eine der Haupt-Fragen, die mich beschäftigen. Welchen Vorteil bringt es, fast sein ganzes Projekt immutable zu machen und bei welchen Klassen macht das überhaupt Sinn, bzw. gar keinen Sinn?

Ahoi,

joaa zwecks Immutability: Das hat ne ganze Reihe ganz interessanter Vorteile, aber zuvor will ich noch kurz auf Ayas Statement eingehen:
Leichte Lesbarkeit und einfach zu verstehender Code kommt in erster Linie dem Entwickler selbst wieder zu Gute - erst in zweiter Linie anderen. Schon allein deswegen lohnt es ganz generell, einfach zu verstehenden Code zu schreiben.

Was die Performance angeht: Dass immutable Klassen nicht zwingend langsamer sein müssen als ihre veränderbaren Kollegen, zeigen die Google Collections sehr eindrucksvoll. Dort ist das verlinkte immutable Set sogar in jedem Fall schneller als das Standard HashSet, was bei Java dabei ist (Und das ist schon recht fix). Intern verwendet das Set von Google sog. Hash Tries, was aktuell ziemlich State-Of-The-Art ist, aber das ist wieder ein anderes Thema

Zurück zu den unmittelbaren Vorzügen von Immutability: Ein schnelles Googlen hat eine Website zu Tage gefördert, welche die meisten dieser Vorzüge nochmal auflistet und kurz erklärt. Diese sind im folgenden:


Dadurch bekommt man also u.A. Multi-Threading quasi geschenkt, was imho ein extremer Vorteil ist. Schon allein dadurch wiegen sich sehr viele Performance-Bedenken auf.
Außerdem ist der Speichermanager der Java VM unheimlich schnell. Die JVM ist verdammt effizient, wenn es um kleine Objekte geht und um viele schnelle Allokationen. Wer sich mit dem Speichermanager dort etwas auskennt, weiß, dass der in verschiedene Pools unterteilt ist. Einer davon (Der eden space) ist speziell für kurzlebige Speicherallokationen ausgelegt und daraufhin optimiert.
Außerdem muss man, wenn man immutable objects kopiert, nur selten den kompletten Objektgraphen neu bauen. In den allermeisten Fällen reicht es, nur einen kleinen Teil vom Graphen auszutauschen. Dabei fallen dann lediglich ein paar Pointer-Umsetzungen statt und die sind bekanntermaßen fix

Ich hoffe, ich konnte damit ein bisschen mehr Einblick verschaffen. Wenn noch was unklar ist, einfach fragen, ich erklär das auch gern ausführlicher und auf Deutsch ^^

Grüße
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Das heißt, will ich den Wert einer Integer Variable in meiner Klasse ändern, muss ich die ganze Klasse neu erzeugen? Oder würde ich komplett auf primitive Datentypen verzichten? (Sprich Integer statt int, Boolean statt boolean etc...) Macht mehr Sinn, denke ich.