und irgendwie pfeif ich auf das "compile once run anywhere" geschiss. cross-platform gui toolkits a la qt, verbreitete sprache wie c++ oder evtl python oder was auch immer, und das ding läuft auch überall (sofern man heute etwas auf mehr als 2-3 platformen am laufen haben will).
jab, hab auch schon ein bisschen was damit geschrieben, wurde aber nicht fertig (war aber trotzdem witzig, ne kleine 2d game engine mit parallax scrolling und plugins). LibSDL ist ne nette Sache für Games, aber ist kein GUI Toolkit. (ich weiss, es gibt ParaGUI und so zeugs, aber ich würd trotzdem kein Notepad.exe mit SDL schreiben)
plattformunabhaengig? ich lach mich krumm, echt. so nen guten witz habe ich schon lange nicht mehr gehoert.
also nicht, dass das konzept es nicht erlauben wuerde... aber man muesste fuer die plattformunabhaengigkeit halt schon jeweils ne vm haben. und da hapert es ziemlich.
Mit unten ist nicht Hirarchisch unten gemeint, oder etwa Geographisch sondern auf Computerschicht.
Ich arbeite ganz gern weit unten. In der Schule machen wir grad nen eigenen Prozessor.
Wenn aber jemand merkt, dass das Objekt welches er braucht einen Bug hat, dann schreib er sein Programm so, dass es diesen Bug umgeht.
Anschliessend fixt jemand den Bug und das Programm läuft nicht mehr. Ausser er arbeitet bei Microsoft, die würden denn Bug dann emulieren, dass das Progamm weiterhin läuft..
hm? Mir leuchtet der Zusammenhang zwischen OO und deinen Punkten nicht ein. Glaubst Du mit prozeduraler Programmierung schreibt man allen Code mehrmals?
ich bin ja nicht grad anti-OO, aber deine Argumente versteh ich nicht.
ich habe eigentlich nur gelernt, dass man bei OO keine sachen machen soll wie "class.variable = wert", weil das unschoen sei und so.
aber es ist imho ein ziemlicher spast, wenn man immer extra ne auslese/reinschreib-funktion basteln muss, weil es den code elend unuebersichtlich macht (hinter einer funktion getspast kann sich schliesslich so etwa alles verstecken, was es an code so gibt, d.h. man muss sich die funktionen immer erst von hand reinziehen, damit man das programm kapiert. und imho sollte man nur funktionen machen fuer aufgaben, die auch etwas komplexer sind als nur einen wert auszulesen oder zu schreiben.
na es dürfte schon vorteile haben. du hast schön vordefiniert wo du wie zugreifen darfst und so. und klasseninternes zeug lässt sich leicht verstecken. vielleicht möchtest du mal mit einer setspast() funktion mehr machen als nur eine variable setzen oder so, dann ists wüst wenn du noch an 500 orten class.spast = sepp hast.
ich finds vom konzept her schon ne feine sache.
eben das ist das problem: wenn man mehr funktionalitaet braucht, kann man ja ne funktion machen.
wenn nicht, ist es quatsch, extra ne "funktion" dafuer zu schreiben.
und ich bin generell eher abgeneigt gegenueber solchen komfortpaketen, wenn sie dafuer die ganze chose lahm machen und nur wenig bringen.
ist ja, wie wenn man nen "suv" kauft und damit in der stadt und so rumholzt. man hat viel komfort, ein "krasses" auto und _koennte_ damit ins gelaende (bei dem beispiel zwar auch nicht :-)) und so... aber es kann ps haben wie es will: es ist einfach nur lahm und unangebracht.
get / set Funktionen braucht man in Java "nur", damits Thread-Safe ist. Es lohnt sich dies aber von Anfang an - auch der Schönheit des Codes zuliebe - vorzusehen.
