DGL
https://delphigl.com/forum/

@Swift Steel aka Yang
https://delphigl.com/forum/viewtopic.php?f=14&t=8889		 Seite 1 von 4
Autor:  Frase [ Do Dez 24, 2009 09:48 ]
Betreff des Beitrags:  @Swift Steel aka Yang
Ahoi,

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

Grüße,
~ Frase
Autor:  Frase [ Do Feb 18, 2010 23:39 ]
Betreff des Beitrags:  Re: Meinungen zu: Yang - Yet another nameless game
(hey, nicht alle auf einmal... *g*)

~ Frase
Autor:  zoiX [ Fr Feb 19, 2010 00:32 ]
Betreff des Beitrags:  Re: Meinungen zu: Yang - Yet another nameless game
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 ;)
Autor:  Ziz [ Fr Feb 19, 2010 13:11 ]
Betreff des Beitrags:  Re: Meinungen zu: Yang - Yet another nameless game
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!
Autor:  Frase [ Fr Feb 19, 2010 18:58 ]
Betreff des Beitrags:  Re: Meinungen zu: Yang - Yet another nameless game
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
Autor:  Flash [ Sa Feb 20, 2010 13:58 ]
Betreff des Beitrags:  Re: Meinungen zu: Yang - Yet another nameless game
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.
Autor:  Frase [ Sa Feb 20, 2010 17:28 ]
Betreff des Beitrags:  Re: Meinungen zu: Yang - Yet another nameless game
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 :D

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
Autor:  Seth [ So Mai 16, 2010 21:04 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
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.
Autor:  Flash [ So Mai 16, 2010 22:43 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
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. ;)
Autor:  Frase [ So Mai 16, 2010 22:48 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
Seth hat geschrieben:
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.

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:
Code:
class Timespan {
    private final Date start;
    private final Date end;

    public Timespan(Date start, Date end) {
        if (end.getTime < start.getTime) {
            throw new IllegalArgumentException("End is behind start");
        }
        this.start = start;
        this.end = end;
    }

    public Date startDate() {
        return start;
    }

    public Date endDate() {
        return end;
    }

Sieht auf den ersten Blick immutable aus - ist es aber nicht:
Code:
Date start = new Date();
Date end = new Date();
TimeSpan span = new TimeSpan(start, end);
start.setYear(42); // <- Autsch


Wenn man nun im Konstruktor von Date Kopien von den reingegebenen Parametern macht...:
Code:
class Timespan {
    private final Date start;
    private final Date end;

    public Timespan(Date start, Date end) {
        if (end.getTime < start.getTime) {
            throw new IllegalArgumentException("End is behind start");
        }
        this.start = new Date(start.getTime());
        this.end = new Date(end.getTime());
    }

    // ...

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:
Code:
class Timespan {
    private final Date start;
    private final Date end;

    public Timespan(Date start, Date end) {
        this.start = new Date(start.getTime());
        this.end = new Date(end.getTime());
        if (this.end.getTime < this.start.getTime) {
            throw new IllegalArgumentException("End is behind start");
        }
    }

    // ...

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:
Code:
Date start = new Date();
Date end = new Date();
TimeSpan span = new TimeSpan(start, end);
span.endDate().setYear(42); // <- Autsch

Wir haben auf das Date noch zugriff über die Accessor-Methoden. Auch das lässt sich leicht ändern:
Code:
    public Date startDate() {
        return new Date(start.getTime());
    }

    public Date endDate() {
        return new Date(end.getTime());
    }


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 :D
  • 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
Autor:  Frase [ So Mai 16, 2010 22:54 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
Flash hat geschrieben:
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. ;)

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:
Code:
public class Scratch {
  public static void main(String[] args) {
    Object meep = null;
   
    new Runnable() {
      @Override
      public void run() {
        System.out.println(meep.hashCode()); // <- "Cannot refer to a non-final variable meep inside an inner class defined in a different method"
      }
    };
  }
}


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
Autor:  Aya [ Mo Mai 17, 2010 11:47 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
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
Autor:  Seth [ Mo Mai 17, 2010 16:18 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
@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?
Autor:  Frase [ Di Mai 18, 2010 17:48 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
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:
Zitat:
Immutable objects greatly simplify your program, since they:
  • are simple to construct, test, and use
  • are automatically thread-safe and have no synchronization issues
  • do not need a copy constructor
  • do not need an implementation of clone
  • allow hashCode to use lazy initialization, and to cache its return value
  • do not need to be copied defensively when used as a field
  • make good Map keys and Set elements (these objects must not change state while in the collection)
  • have their class invariant established once upon construction, and it never needs to be checked again
  • always have "failure atomicity" (a term used by Joshua Bloch) : if an immutable object throws an exception, it's never left in an undesirable or indeterminate state


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
Autor:  Seth [ Di Mai 18, 2010 23:27 ]
Betreff des Beitrags:  Re: @Yang - Yet another nameless game
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.
Seite 1 von 4 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/