Guten Morgen
Markus Gaelli wrote:
Hi Leute,
Der Grund: Es gibt zumindest zwei Wege, einen Button einfacher zu machen, als Du ihn beschreibst:
Darüber kann man streiten ;-)
Here we go... :-) Nein, im Ernst, an alle zu posten, dass ich gleich zwei einfachere Lösungen wüsste, und dann auch noch Chris Seite umzubenennen, war ein wenig großspurig von mir. Ich hätte mich natürlich vorher mit ihm darüber abstimmen müssen, sorry, soll nicht mehr vorkommen.
Ich denke, die Diskussion wirft aber eine wichtige Frage auf:
An wen richten sich unsere Tutorials? Haben wir eine Hauptzielgruppe? Chris hat eher Smalltalk-Entwickler im Sinn, die eine gute open-source Entwicklungsumgebung suchen, ich dachte eher an Kinder/Eltern/Lehrer oder "Omniuser" (was war da gleich die beste deutsche Übersetzung?)
Korrekt! Ich richte mich eher an Entwickler, die im Sourcode arbeiten und versuche immer so viel wie möglich 'Schnickschnack' zu vermeiden. Das mag an meinem Unix Hintergrund liegen. Kann Vor- und Nachteil sein. Deswegen hoffe ich auch auf ein kleines Image. Wenn ich mal eine Netzwerkapplikation in Squeak baue, will ich nicht ständig Morphic oder E-Toys bei Runtime mitschleppen.
Vielleicht sollten wir da mehrere Zweige aufmachen und in der Überschrift klar machen, für wen das Tutorial gedacht ist.
Ich werde meine Squeak Sachen immer auf meiner Website pflegen. Von daher ist es vielleicht sinnvoll, ein paar Worte auf dem Swiki zu schreiben, wo die jeweilige Zielgruppe zum Ziel kommt, oder den Swiki in der Kategorie eben zu untergliedern.
Zum einen via E-Toys, das habe ich zunächst mal erklärt (Bilder lade ich up, sobald ich das Upload-Kennwort wieder weiß), zum zweiten, wenn Du es "textprogrammatisch" machen möchtest, brauchst Du "nur" die handlesMouseDown: und handlesMouseOver: in Morph zu überschreiben und kommst dann ganz ohne when:... aus.
Schon, schon, aber die Frage ob #handlesMouseDown: einfacher ist als "on:send:to:" ist schwierig zu beantworten.
Das Tutorial für den E-Toy Button nebst Screenshots und Filmaufnahme ist mir wichtiger, als die Antwort auf die Frage, welche der Smalltalk-Lösungen tatsächlich einfacher ist oder nicht. Trotzdem die längere Antwort zum anderen Teil:
Es gibt zumindest zwei Probleme damit: Zum einen muss man sich an fünfhundert verschiedene #handlesFooBar: Methoden erinnern, und wenn man eine vergisst passiert rein gar nix (und solche Sachen sind wirklich schwer zu finden).
Stimmt, ein Problem was ich hatte, war, dass ich erstmal #handlesMouseEnter: anstatt #handlesMouseOver: überschrieben hatte, da tat sich auch erst mal nicht viel. Wenn man mittels leerer Templatemethoden a la Morph >> #fooBar die #handlesFooBar ganz loswürde, wäre das noch besser. Aber die Schwierigkeiten, Morph zu vereinfachen, sind genug diskutiert worden, vielleicht gibt es ja da demnächst was besseres...
Demzufolge ist das "explizite Setup" mittels #on:send:to: u.U. einfacher zu merken - es hat weniger Constraints (die Methode kann irgendwie heissen)
Könnte man in mouseDown: umleiten...
und man muss sich nur ein Konzept merken. Zudem ist das Setup zentralisiert, was bedeutet das wenn jemand rausfinden möchte "was dieses Ding macht" kann er in die Initialisierung reinschauen und muss nicht wild durch die Klasse browsen.
Genau! Ich krieg immer einen Hals, wenn ich mich durch manchmal 5 verschiedene Methoden durchklicken muss, bis ich die Funktionalität finde, die ich suche.
Manchmal habe ich den Eindruck das Smalltalk Lernen zwar das Denken in OO extrem fördert, aber einem noch lang nichts über Design beibringt.
Das Argument kommt mir schon vom Visitior-Pattern bekannt vor, ich mag es nicht so gern, weil wir ja sonst bei OO immer der Verteilung das Wort reden, bin wohl eher der wilde Typ :-) ...solange die Methodennamen sprechend genug sind, aber das ist vielleicht Mentalitätssache.
Vielleicht finde ich es auch einfach schwieriger, den richtigen Event-Namen zu finden, als die Methode, die ich überschreiben muss.
Wir sind uns einig, dass der E-Toy-Weg da der eleganteste ist.
Zum anderen, ist die Implementation von #mouseDown: o.ä. Methoden eigentlich eine Modifikation des Frameworks, was bedeutet, man muss zwangsläufig die "super" Methoden verwenden, was für mich eine (unnötige) Verkomplizierung des Tutorials darstellt. Du bist Dir übrigens bewusst, dass Dein Beispiel buggy ist, oder?! ;-) Weder #mouseEnter:, noch #mouseLeave:, noch #mouseUp: verwenden die "super" Implementationen, was sie eigentlich müssten (nicht so in Chris' Beispiel).
Ich verstehe aber nicht, warum ich super rufen muss. Ich muss es dann rufen, wenn ich event-handling, wie Ihr es vorschlagt, benütze. Will ich ja nicht, alles was der Morph nach click tun soll, definiere ich in mouseDown: Oder was übersehe ich? YAGN.
Es kommt halt darauf an, ob der owner des Morph bei einem Event auch noch etwas tun will und den Event noch haben will. Wie Andreas sagt, sind es zwei verschiedene Frameworks.
Folgendes Snippet zeigt, dass der Prozentsatz von "super-rufern" in 3.4 eher gering ist:
#(#mouseDown: #mouseEnter: #mouseLeave:) collect: [:aSymbol | someMethods := Morph allSubclasses select: [:e | e methodDict includesKey: aSymbol]. someSuperCallers := someMethods select: [:e | (e methodDict at: aSymbol) sendsToSuper and: [(e superclass lookupSelector: aSymbol) = (Morph compiledMethodAt: aSymbol)]]. someSuperCallers size / someMethods size]
#((11/71) (1/21) (1/18))
Wenn es denn falsch ist, bin ich zumindest nicht alleine... ;-) Ist das dann was für die MorphCleaningGroup?
Es ist nicht falsch, es schränkt nur eventuell noch benötigte Funktionalität ein.
Der einzige echte "Nachteil" der Verwendung von #on:send:to: ist, dass der Eventtrigger "zu weit entfernt" von der Methode ist, die darauf reagiert (und die Syntax ist auch nicht unbedingt trivial). Hier sind die eToys weit überlegen. Selbiges übrigens für #triggerEvent: etc.
Ob es aber "einfacher" ist, eine korrekte Implementation der Eventhandler zu schreiben oder #on:send:to: zu benutzen kann man also bezweifeln.
Ciao,
- Andreas
Viele Grüße,
Markus
Ich bin sowieso der Meinung, das das Morphic Eventsystem auf das in Object umgestellt werden sollte. Das ist zwar Arbeit, aber es schafft mehr Übersicht. Ich hoffe auf MCP. Wenn Morph die gleiche Funktionalität zur Verfügung hat, sollte es den kleinsten gemeinsamen Nenner nutzen ... und der liegt semantisch gesehen in Object.
Ich habe mal versucht, in das Morphic Eventsystem einzutauchen und es besser zu verstehen um es umzustellen, aber das habe ich nach zu viel Klickerei im Browser aufgegeben.
schönen Sonntag Chris Burkert