> 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.
Aber Du verstehst mich dauernd falsch weil Du zu 80% völlig
schwachsinnige Schlussfolgernungen ziehst und anhand derer die
Untauglichkeit meiner Ideen beweisen willst.
>> Es ist hier garnichts in seiner Funktion eingeschränkt
>> da dieses Feature nur benutzt werden würde wenn man keine
>> Polymorphie an dieser Stelle brauchen würde.
> Das wäre der Fall, wenn es der JIT automatisch so optimiert. Bei
> expliziter Angabe durch eine Syntax kann ich Polymorphie später nicht
> mehr einsetzen ohne den Typ wieder zurückzuändern in ein vollwertiges
> Objekt. Drum ist es besser, der JIT entscheidet, ob er es "für voll"
> nehmen muß.
Das kann er aber oft nicht und muss im Zweifelsfall das Objekt als
Referenz ansprechen.
>>> ... der einzige Unterschied wäre dann, daß sie auch als private
>>> Felder von T überall in T zugreifbar wären, es also rein
freiwillig
>>> wäre, wenn ich sie nur in bestimmten Methoden von T (die sonst in
X
>>> lägen und nicht polymorph wären) anspreche.
>> Wie praktikabel dein Ersatzvorschlag!
>> An die Code-Wiedervwedendung denkst Du hier nicht im Geringsten.
> Wiederverwendung ginge doch.
Klar, indem ich dann Code vom Objekt der eingebettenten Klasse
manuell in die enthaltene Klasse kopiere - toller Vorschlag!
>> Du bekommst die Kapselung und Code-Wiederverwendung für
>> Polymorphie die man an dieser Stelle nicht benötigt.
> Wiederverwendung hab ich sowieso.
Nein, nicht wenn ich Code so wie Du vorschlägst in die enthaltende
Klasse kopiere.
>>> Anfängerfehler bez. final zum Opfer gefallen zu sein und es für
was
>>> ähnliches wie const zu halten.
>> Nein, Du hast final hier definiert als...
> Bitte nicht noch mehr Unwahrheiten!
> Das Schlüsselwort final exisitert in Java (wovon wir die ganze Zeit
> über sprechen) und ist dort seit langer Zeit definiert - aber nicht
> von mir. Wenn du das nicht weißt oder eine Referenz auf diesen
> Begriff nicht erkennst...
Es gibt hier aber keine Referenz (eine final-Referenz kann ich z.B.
im Konstruktor noch ändern; das was ich hier habe lässt sich nicht
ändern).
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.
>>> ..sind sie ganz gewaltig "vollwertig", nicht wahr?
>> Sie sind nur nicht polymorph
> Oben schrubst du aber, daß sie nicht ohne einhüllende Objekte
> existieren können, das ist etwas ganz anderes als "nur nicht
> polymorph".
Ich meinte die Einschränkungen. Das was Du sagst ist keine
Einschränkung da man Objekte die nicht eingebettet sind sowieso nicht
als solche definieren würde.
>> ...bei den meisten Objekten nicht
>> benötigt wird ist das kein Problem.
> 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. Wieso soll man auch ein Problem darin haben,
daß ein Objekt in einem Objekt nicht polymoph sein kann wenn man ein
Feature nutzt das die Performance für den Fall verbessert, daß es
nicht polymoph zu sein braucht?
>> (abgesehen davon, daß Escape-Analysis nicht die Anlegbarkeit
>> von Objekten in Objekten ermittelt, sondern die Anlegbarkeit
>> im CPU-Stack).
> Nicht generell gültig.
Escape-Analysis ist aber von denen die JIT-Compiler entwickeln anders
definiert.
>> Objekte die in einem Array liegen sind um Größenordnungen
>> schwieriger zu realisieren.
> Soso, jetzt geht es nur noch darum... jetzt sollen wir uns also ein
> halbes Dutzend Postings in deinem unsäglichen Stil darüber den Kopf
> zerbrechen, was jetzt bei Arrays nun genau anders ist? Nein danke!
> Denn:
> 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.
> Wenn die Übergabe an Reflectionmethoden als Verletzung der Bedingung
> aufgefaßt werden soll, kann tatsächlich die Einbettung nicht vorgenommen
> werden; ...
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
dessen Metainformationen die die Reflection nutzt "reflektieren"
diese Tricks für den Reflection-Mechanismus.
> 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.
Aber Du verstehst mich dauernd falsch weil Du zu 80% völlig
schwachsinnige Schlussfolgernungen ziehst und anhand derer die
Untauglichkeit meiner Ideen beweisen willst.
>> Es ist hier garnichts in seiner Funktion eingeschränkt
>> da dieses Feature nur benutzt werden würde wenn man keine
>> Polymorphie an dieser Stelle brauchen würde.
> Das wäre der Fall, wenn es der JIT automatisch so optimiert. Bei
> expliziter Angabe durch eine Syntax kann ich Polymorphie später nicht
> mehr einsetzen ohne den Typ wieder zurückzuändern in ein vollwertiges
> Objekt. Drum ist es besser, der JIT entscheidet, ob er es "für voll"
> nehmen muß.
Das kann er aber oft nicht und muss im Zweifelsfall das Objekt als
Referenz ansprechen.
>>> ... der einzige Unterschied wäre dann, daß sie auch als private
>>> Felder von T überall in T zugreifbar wären, es also rein
freiwillig
>>> wäre, wenn ich sie nur in bestimmten Methoden von T (die sonst in
X
>>> lägen und nicht polymorph wären) anspreche.
>> Wie praktikabel dein Ersatzvorschlag!
>> An die Code-Wiedervwedendung denkst Du hier nicht im Geringsten.
> Wiederverwendung ginge doch.
Klar, indem ich dann Code vom Objekt der eingebettenten Klasse
manuell in die enthaltene Klasse kopiere - toller Vorschlag!
>> Du bekommst die Kapselung und Code-Wiederverwendung für
>> Polymorphie die man an dieser Stelle nicht benötigt.
> Wiederverwendung hab ich sowieso.
Nein, nicht wenn ich Code so wie Du vorschlägst in die enthaltende
Klasse kopiere.
>>> Anfängerfehler bez. final zum Opfer gefallen zu sein und es für
was
>>> ähnliches wie const zu halten.
>> Nein, Du hast final hier definiert als...
> Bitte nicht noch mehr Unwahrheiten!
> Das Schlüsselwort final exisitert in Java (wovon wir die ganze Zeit
> über sprechen) und ist dort seit langer Zeit definiert - aber nicht
> von mir. Wenn du das nicht weißt oder eine Referenz auf diesen
> Begriff nicht erkennst...
Es gibt hier aber keine Referenz (eine final-Referenz kann ich z.B.
im Konstruktor noch ändern; das was ich hier habe lässt sich nicht
ändern).
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.
>>> ..sind sie ganz gewaltig "vollwertig", nicht wahr?
>> Sie sind nur nicht polymorph
> Oben schrubst du aber, daß sie nicht ohne einhüllende Objekte
> existieren können, das ist etwas ganz anderes als "nur nicht
> polymorph".
Ich meinte die Einschränkungen. Das was Du sagst ist keine
Einschränkung da man Objekte die nicht eingebettet sind sowieso nicht
als solche definieren würde.
>> ...bei den meisten Objekten nicht
>> benötigt wird ist das kein Problem.
> 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. Wieso soll man auch ein Problem darin haben,
daß ein Objekt in einem Objekt nicht polymoph sein kann wenn man ein
Feature nutzt das die Performance für den Fall verbessert, daß es
nicht polymoph zu sein braucht?
>> (abgesehen davon, daß Escape-Analysis nicht die Anlegbarkeit
>> von Objekten in Objekten ermittelt, sondern die Anlegbarkeit
>> im CPU-Stack).
> Nicht generell gültig.
Escape-Analysis ist aber von denen die JIT-Compiler entwickeln anders
definiert.
>> Objekte die in einem Array liegen sind um Größenordnungen
>> schwieriger zu realisieren.
> Soso, jetzt geht es nur noch darum... jetzt sollen wir uns also ein
> halbes Dutzend Postings in deinem unsäglichen Stil darüber den Kopf
> zerbrechen, was jetzt bei Arrays nun genau anders ist? Nein danke!
> Denn:
> 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.
> Wenn die Übergabe an Reflectionmethoden als Verletzung der Bedingung
> aufgefaßt werden soll, kann tatsächlich die Einbettung nicht vorgenommen
> werden; ...
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
dessen Metainformationen die die Reflection nutzt "reflektieren"
diese Tricks für den Reflection-Mechanismus.