Re: Objekte und Zugriffs-Funktionen

[Jens-Peer Kuska <kuska@XXXXXXX.de>]

Hallo,

> zugegeben die formulierung zum zugriff auf die pixel daten sieht recht nett
> aus.

Danke.

> 
> gr /. Graphics[Raster[m_,___],___] :> m
> 
> doch muesst ihr angeben dass rund um das objekt euer begierde zunaechst
> einmal Graphics[] steht, weiters muesst ihr angeben, dass dann Raster[] um
> eure date geschlungen ist und schliesslich muest ihr noch angeben das
> Raster[] von sontigen infos gefolgt wird.
> 
> damit erfordert der zugriff auch nicht mehr und nicht weniger sondern sogar
> genau die gleiche info ueber die zu grunde liegende struktur wie:
> 
> First@First@gr
> 
> zugegeben muss man das mit der ersten methode anhand der beschreibung der
> daten zugegriffen wird.

Es gibt noch ein paar mehr Varianten 

gr[[1,1]]

Cases[gr, _?MatrixQ, Infinity]

Wobei ich beim letzten Beispiel nicht wissen muss, das
Graphics[Raster[__],_] in
gr steht.

> das scheint mir aber noch nicht sehr objektorientiert.

Soll es ja auch nicht!! Wenn man eine (wunderbare) funktional-logische 
Programmiersprache hat ist es Unsinn diese mit dem objektorientierten 
Schnickschak zu versehen. 

> vielmehr ist das
> vergleichbar mit den aus "pascal" gewohnten datenzugriffen ueber "records"
> bezw. den "structure" aus "C".

Programier-Paradigmen aller L"ander vereinigt euch!

Die einer funktionalen Sprache eigene Formulierung w"are

someBitmapFunction[Graphics[r_Raster,___]]:=someBitmapFunction[r]

someBitmapFunction[lst:{__Graphics}]:=someBitmapFuntion /@ lst

someBitmapFunction[Raster[m_,args___]]:=
   Block[{(* ein paar Variablen *)}, 
      (* ein Paar Modifikationen  m ->m1 *)
       Graphics[Raster[m1,args]]
     ]

OOP und funktionale Sprachen sind was Daten angeht gerade invers.
Bei OOP ist das Datum die zentrale Instanz, bei funktionalen Sprachen
die Funktion. W"arend man bei OOP f"ur jedes Datum eigene Funktionen
erzeugt
erstellt man bei funktionaler Programmierung eine Funktion f"ur (im
besten Fall)
f"ur alle Daten. 

Das diese reine Lehre manchmal nicht vollst"andig umgesetzt (man kann in
LISP
Variablen vereinbaren) wird steht auf einem anderen Blatt.

Das Problem mit OOP ist, man muss sich "uberlegen "Was kann dieses
Objekt alles tun",
bei funktionaler Programierierung muss man "uberlegen auf welche Daten
ist eine
Funktion anwendbar. Also entweder alle m"oglichen Aktionen mit einem
Datum oder
eine Aktion mit allen m"oglichen Daten.

Letzters ist nat"urlich logischer.

> 
> in beiden faellen kommt man in schwierigkeiten wenn die struktur der daten
> sich aendert ( siehe Pallette, RGB, Graylevel, etc) mann muss dann den
> zugriffsmechanismus auch modifizieren.

Naja, eigentlich nicht, es ist ja immer eine Matrix in der, je nach
Format
stehen halt bloss Verweise auf eine Palette, Grauwerte oder RGB Tripel
drin.
Solange aber Bitmaps rechteckig bleiben witd sich die Matrix nicht
"andern, nur
die Bedeutung der Eintr"age "andert sich.

> 
> Das problem wurzelt wie schon frueher von euch angedeutet in der mangelnden
> objektorintiertheit der Graphics, bezw, Raster implementation mathematicas.

Probleme Wurzeln immer nur in einer Objektorientiertheit, sie entstehen
"uberhaupt erst durch OOP. Die Idee der Objektorientierung ist einfach
zu absurd. Ein Programm wird f"ur eine bestimmte Aufgabe (Funktion)
geschrieben und 
nicht daf"ur im Hauptspeicher rumzuliegen, mit seinen Methoden zu
spielen und via
Messsages small talk mit anderen Objekten zu f"uhren.
Das Programm soll seine Funktion unter allen Umst"anden erf"ullen, 
egal mit welchen Daten. 

OOP ist eigentlich f"ur die Simulation von komplexen Systemen erfunden
worden.
Die Objekte  bekommen dann Nachrichten von anderen Objekten und
versenden dann
ihrerseits wieder Nachrichten. Also das KaffeTassenObjekt schickt die
Nachricht 
"Ich bin mit heissem Kaffee gef"ullt."
das ProgrammiererObjekt aktiviert seine KaffeTrinken() Methode die
der Tasse mitteilt Du bist leer und dem ProgrammiererFrauenObjekt 
"Mein Kaffee ist alle.", das ProgrammiererFrauenObjekt aktiviert seine
Methode MachIchNicht() und schickt dem ProgrammiererObjekt die Nachricht
"Mach Die deinen Kaffee alleine Du Pascha.", das ProgrammiererObjekt
aktiviert
seine Methode KaffeeHolen() ...

Zweifelos sind solche Simulationen von hohem Wert, z. B. als
Bildschirmschoner.
Das war's dann aber auch. Mit Mathematica wollte ich eigentlich 
was Sinvolles machen -- was gerade deshalb so prima geht weil es *nicht*
Objektorientiert ist.

Gruss
  Jens