Mäusespeck schrieb am 26. Juni 2006 1:59
> > Ich hab langsam genug von deiner Art, sich staändig selbst zu
> > widersprechen, andauernd erst dies, dann das Gegenteil zu behaupten,
> > nicht richtig mitzulesen und nur Invektiven auszuteilen statt Stoff
> > für eine Diskussion.
>
> Das habe ich alles nicht getan.
J ne, is klar... ;)
> Aber Du verstehst mich dauernd falsch
Ich versteh dich ganz richtig. Du bist halt ein weiterer Troll in
diesem Forum. Und willst mir das besonders eindrücklich beweisen :-)
> > Wiederverwendung ginge doch.
>
> Klar, indem ich dann Code vom Objekt der eingebettenten Klasse
> manuell in die enthaltene Klasse kopiere - toller Vorschlag!
Nichts dergleichen habe ich vorgeschlagen. Das ist deine unsinnig
Schlußfolgerung und damit willst du beweisen, daß meine Kritik an
deinen kaum artikulierten Äußerungen unberechtigt ist? Na du bist mir
aber ein Herzchen ;)
> > Wiederverwendung hab ich sowieso.
>
> Nein, nicht wenn ich Code so wie Du vorschlägst
> in die enthaltende Klasse kopiere.
Die Wiederholung der falschen Behauptung über etwas, was du zwar
schwachsinnig geschlußfolgert hast, ich jedoch nicht so vorgeschlagen
habe, rettet deine Argumentation auch nicht mehr.
> > > Nein, Du hast final hier definiert als...
>
> > Bitte nicht noch mehr Unwahrheiten!
Ja, bittebitte!
Denn das Schlüsselwort final existiert in Java
> Es gibt hier aber keine Referenz (eine final-Referenz kann ich z.B.
> im Konstruktor noch ändern;
Und danach kann ich es als final betrachten.
das was ich hier habe lässt sich nicht ändern).
Ist dann auch final.
> final hat in Java definierte Bedeutungen für zwei Fälle. Und aus
> diesem Fällen lässt sich keien Bedeutung für meinen Fall herleiten.#
Das beweist aber auch nicht, daß du keinen Blödsinn verzapfst.
Du kannst ja nicht mal erklären, wie man Kapselung und
Wiederverwendung, auf denen du manchmal herumreitest, dann wieder von
dir weist, damit etwas am Hut zu haben (siehe anderen Post weiter
oben) dann betreiben soll - ohne das "vollwertige" Objekt
referenzieren und seine Methoden irgendwie aufrufen zu können.
Dann schlißt du draus, daß man nur die Felder und den Code in die
enthaltene Klasse kopieren kann und behauptest flugs, das hätt ich
vorgeschlagen, das sei aber wider die Wiederverwendung und deshalb,
so folgest du, sei das alles Unsinn - außer natürlich deinen eigenen
unausgegorenen und unzusammenhängend und widersprüchlich
vorgetragenen "Gedankengängen". Na bravo... :-(
Was werd' ich wohl von dir jetzt halten?
Bingo!
> > Alles, was dir nicht in den Kram paßt,
> > ist für gewöhnlich "kein Problem".
>
> Das hat zumindest noch keiner bemängelt der diese Features
> in anderen Sprachen genutzt hat.
Jetzt wüßte ich gerne, welche das sind. Denn anfangs brabbeltest du
nur was von structs in C#/.NET (im OP) und später bestandest du
vehement darauf, daß das was ganz anderes sei (was dir gerade in den
Kram paßt, eben... alles andere ist ja für gewöhnlich "kein Problem"
;) und nun.... ja, wir haben keine Sprache, die genau dieses Feature
hat, präsentiert bekommen - wohl wiel dir Schwammigkeit hervorragend
in den Kram paßt.
> Escape-Analysis ist aber von denen die JIT-Compiler
> entwickeln anders definiert.
Escape-Analysis ist ein allgemeiner Begriff und nicht von dern
JVM-Entwicklern geschaffen. Sowas gibt's schon länger. Ich dachte, du
wüßtest das.
Ach so... natürlich paßt dir das nicht in den Kram (hätt ich gleich
drauf kommen können ;)
> > Es ist nicht trivial das im JIT zu optimieren, aber ebenso wie
> > Stack Allocation, die auch nicht ganz trivial ist, wäre es
> > durchaus zu schaffen.
>
> Klar, Du meinst also man könnte Code darauf untersuchen ob das von
> ihm erstellte Array zur Laufzeit spärlich oder voll besetzt sein
> wird. Das geht nur in seltenen Einzelfällen.
Mir egal. Sparse Arrays haben nun wiederum gar nichts mit dem Thema
der Einbettung zu tu, die würde man im Gegenteil gar nicht mit
Einbettung lösen. Die Sprunghaftigkeit, mit der du zu völlig anderen
Themen wechselst, die dir gerade als Ablenkungsmanöver in den Kram
passen, mit dem diskutierten aber gar nichts zu tun haben, ist
sagenhaft :-(
> Reflection ist auch mit dynamischer Einbettung durch den JIT - soweit
> die in einzelfällen durch diesen erreicht werden kann - problemlos
> möglich. Die Reflection kennt ja auch die Tricks des Compilers und
Ja ne, is klar: Zunächst ist Reflection das große Problem, das
beweisen soll, daß ich Unrecht habe und daß der JIT die Möglichkeit
der Einbettung gar nicht überall erkennen kann, sondern nur in den
wenigsten Fällen. Dann, wenn es dir in den Kram paßt, ist Reflection
plötzlich kein Problem mehr und kennt die Compilertricks und paßt ja
prima zusammen. Ne du, is schon klar...
:-( was 'ne Zeitverschwendung ist das hier mit dir...)
> > Ich hab langsam genug von deiner Art, sich staändig selbst zu
> > widersprechen, andauernd erst dies, dann das Gegenteil zu behaupten,
> > nicht richtig mitzulesen und nur Invektiven auszuteilen statt Stoff
> > für eine Diskussion.
>
> Das habe ich alles nicht getan.
J ne, is klar... ;)
> Aber Du verstehst mich dauernd falsch
Ich versteh dich ganz richtig. Du bist halt ein weiterer Troll in
diesem Forum. Und willst mir das besonders eindrücklich beweisen :-)
> > Wiederverwendung ginge doch.
>
> Klar, indem ich dann Code vom Objekt der eingebettenten Klasse
> manuell in die enthaltene Klasse kopiere - toller Vorschlag!
Nichts dergleichen habe ich vorgeschlagen. Das ist deine unsinnig
Schlußfolgerung und damit willst du beweisen, daß meine Kritik an
deinen kaum artikulierten Äußerungen unberechtigt ist? Na du bist mir
aber ein Herzchen ;)
> > Wiederverwendung hab ich sowieso.
>
> Nein, nicht wenn ich Code so wie Du vorschlägst
> in die enthaltende Klasse kopiere.
Die Wiederholung der falschen Behauptung über etwas, was du zwar
schwachsinnig geschlußfolgert hast, ich jedoch nicht so vorgeschlagen
habe, rettet deine Argumentation auch nicht mehr.
> > > Nein, Du hast final hier definiert als...
>
> > Bitte nicht noch mehr Unwahrheiten!
Ja, bittebitte!
Denn das Schlüsselwort final existiert in Java
> Es gibt hier aber keine Referenz (eine final-Referenz kann ich z.B.
> im Konstruktor noch ändern;
Und danach kann ich es als final betrachten.
das was ich hier habe lässt sich nicht ändern).
Ist dann auch final.
> final hat in Java definierte Bedeutungen für zwei Fälle. Und aus
> diesem Fällen lässt sich keien Bedeutung für meinen Fall herleiten.#
Das beweist aber auch nicht, daß du keinen Blödsinn verzapfst.
Du kannst ja nicht mal erklären, wie man Kapselung und
Wiederverwendung, auf denen du manchmal herumreitest, dann wieder von
dir weist, damit etwas am Hut zu haben (siehe anderen Post weiter
oben) dann betreiben soll - ohne das "vollwertige" Objekt
referenzieren und seine Methoden irgendwie aufrufen zu können.
Dann schlißt du draus, daß man nur die Felder und den Code in die
enthaltene Klasse kopieren kann und behauptest flugs, das hätt ich
vorgeschlagen, das sei aber wider die Wiederverwendung und deshalb,
so folgest du, sei das alles Unsinn - außer natürlich deinen eigenen
unausgegorenen und unzusammenhängend und widersprüchlich
vorgetragenen "Gedankengängen". Na bravo... :-(
Was werd' ich wohl von dir jetzt halten?
Bingo!
> > Alles, was dir nicht in den Kram paßt,
> > ist für gewöhnlich "kein Problem".
>
> Das hat zumindest noch keiner bemängelt der diese Features
> in anderen Sprachen genutzt hat.
Jetzt wüßte ich gerne, welche das sind. Denn anfangs brabbeltest du
nur was von structs in C#/.NET (im OP) und später bestandest du
vehement darauf, daß das was ganz anderes sei (was dir gerade in den
Kram paßt, eben... alles andere ist ja für gewöhnlich "kein Problem"
;) und nun.... ja, wir haben keine Sprache, die genau dieses Feature
hat, präsentiert bekommen - wohl wiel dir Schwammigkeit hervorragend
in den Kram paßt.
> Escape-Analysis ist aber von denen die JIT-Compiler
> entwickeln anders definiert.
Escape-Analysis ist ein allgemeiner Begriff und nicht von dern
JVM-Entwicklern geschaffen. Sowas gibt's schon länger. Ich dachte, du
wüßtest das.
Ach so... natürlich paßt dir das nicht in den Kram (hätt ich gleich
drauf kommen können ;)
> > Es ist nicht trivial das im JIT zu optimieren, aber ebenso wie
> > Stack Allocation, die auch nicht ganz trivial ist, wäre es
> > durchaus zu schaffen.
>
> Klar, Du meinst also man könnte Code darauf untersuchen ob das von
> ihm erstellte Array zur Laufzeit spärlich oder voll besetzt sein
> wird. Das geht nur in seltenen Einzelfällen.
Mir egal. Sparse Arrays haben nun wiederum gar nichts mit dem Thema
der Einbettung zu tu, die würde man im Gegenteil gar nicht mit
Einbettung lösen. Die Sprunghaftigkeit, mit der du zu völlig anderen
Themen wechselst, die dir gerade als Ablenkungsmanöver in den Kram
passen, mit dem diskutierten aber gar nichts zu tun haben, ist
sagenhaft :-(
> Reflection ist auch mit dynamischer Einbettung durch den JIT - soweit
> die in einzelfällen durch diesen erreicht werden kann - problemlos
> möglich. Die Reflection kennt ja auch die Tricks des Compilers und
Ja ne, is klar: Zunächst ist Reflection das große Problem, das
beweisen soll, daß ich Unrecht habe und daß der JIT die Möglichkeit
der Einbettung gar nicht überall erkennen kann, sondern nur in den
wenigsten Fällen. Dann, wenn es dir in den Kram paßt, ist Reflection
plötzlich kein Problem mehr und kennt die Compilertricks und paßt ja
prima zusammen. Ne du, is schon klar...
:-( was 'ne Zeitverschwendung ist das hier mit dir...)