Schlüsselwort zu belegen

[codingfriend]

Hallo an alle, Java hat ja noch 2 freie Schlüsselwörter.
Mich würde mal interessieren, wir ihr sie belegen würdet,
bzw. welche Funktionen euch noch fehlen?

Mir fällt nur zu const was ein:
Es fehlt meiner Meinung nach eine Funktion,
Instanzen einer Klasse read-only zu machen,
ohne sie neu implementieren zu müssen,;(
denn final lässt einen ja nur Referenzen nicht umbiegen.
Man könnte dann ein read-only Objekt so deklarieren:

const Klassenname einReadOnlyObjekt;

Um dann noch mit Get-Methoden darauf zugreifen zu können,
könnte man const in die Methoden-Signatur aufnehmen,
wie in C++:

Methodentyp eineReadOnlyMethode (Parameter) const{...}

Wie würdet ihr sie belegen?:reflect:
Was fehlt euch noch?:reflect:

PS: Java ist ja Open-Source ... :hihi::hihi:

 

[Gonzo17]

Hm, ich bin ja noch relativ neu in Java und hab nicht viel Erfahrung, aber ich sehe grade nicht, was der Unterschied zu der Kombination "static final" wäre. Damit kann man doch auf eine Variable einer Klasse zugreifen, ohne ein Objekt dieser Klasse erstellen zu müssen, oder? ???:L

 

[codingfriend]

Ich habe mich wohl nicht ganz klar ausgedrückt.

Ich meinte, dass man,
wenn man ein Objekt als const deklariert (was es (noch) nicht gibt),
die Anfangswerte vom Konstruktor nicht ändern kann.
Dies könnte bei Methoden nützlich sein,
die Objekte nur als Informationsquelle nutzen sollen und
nicht die Membervariablen über Set-Funktionen ändern können sollen.

Bei der Kombination static final existiert einmal pro ganze Klasse eine Referenz
(oder ein primitiver Typ, ist aber dafür nicht von Belang),
die nicht "umgebogen" werden kann
(also ist nicht möglich:

dieStatischFinaleReferenz = ...;

),
wohl aber können die Membervariablen verändert werden!:autsch:
Probier den angehängten Code aus (in .java umbennenen).
(Ich hoffe, du verstehst mein Englisch. Ich mache erst 5 Jahre Englisch in der Schule.)

 

[eRaaaa]

hm, ok dann belehre mich bitte auch gleich und beantworte mir bitte auch eine frage:

was wäre da jetzt der unterschied, bzw besser, als die member des objekts final zu deklarieren?
wenn ich alle klassenattribute final deklariere, hab ich dann nicht ein read-only objekt?

 

[Marco13]

wenn ich alle klassenattribute final deklariere, hab ich doch ein read-only objekt, oder?

Jein - das ist genau der Punkt: Man hat dann NUR read-only-Objekte. Ich denke, es geht darum, dass man sowas machen kann wie

Thing t = new Thing();
t.setSomeValue(123);

const Thing ct = t;
t.setSomeValue(234); // *compiler motzt wegen const-veränderung*

 

[Painii]

was wäre da jetzt der unterschied, bzw besser, als die member des objekts final zu deklarieren?

Unterschied zwischen final und static final?
Bei static final wird einmal der Wert festgelegt wenn die Klasse initialisiert wird, bei nur final wird das bei jedem neuen Objekt gemacht:

public static final long staticFinalLong = System.currentTimeMillis();
public final long finalLong = System.currentTimeMillis();
public static void main(String[] args){
 Test test1=new Test(); //staticFinalLong und finalLong von test1 aufbauen
 Test test2=new Test(); //nurnoch finalLong von test2 bauen, staticFinalLong wird nichtmehr verändert
}

[quote]wenn ich alle klassenattribute final deklariere, hab ich doch ein read-only objekt, oder?[/QUOTE]
Nein, denn du kannst (bei nicht-primitiven) ja noch Member der Variablen verändern.
Für read-only sorgen immutables -> Die können nach der Erstellung nichtmehr verändert werden (String ist z.b. immutable).
Link dazu: [url=http://www.javapractices.com/topic/TopicAction.do?Id=29]Java Practices -> Immutable objects[/url]

 

[Atze]

ich glaub ihm gehts aber darum, jedes object mit dem schlüsselwort on the fly unveränderbar zu machen!

also ich hab dann ne klasse, in der nicht alle member final sind und die ich ganz normal zur laufzeit ändern kann.
dann kann ich aber das gleiche object - also eine neue instanz - aber zwei zeilen weiter auch als readonly benutzen ohne an den code der klasse zu müssen, und somit auch das verhalten des objekts 2 zeilen vorher zu verändern

hm, hört sich schon ganz sinnvoll an, jedenfalls im ersten moment. wüßte sonst außer über n interface nicht, wie man das sonst "auf die schnelle" machen kann, und das heißt auch wieder interface + 2 implementierungen. oder gäbs da noch n anderen ansatz? bringt mich echt zum phantasieren netter gedankengang @ codingfriend

bin in der api mal über GuardedObject gestolpert, aber glaub da ging es in die richtung rechteverwaltung, muss ich mir nochmal anschauen

 

[codingfriend]

Hallo an alle, ich demonstriere mal wie ich mir das vorstelle:
@Marco und Atze: Genau das meine ich.
In C++ z.B. ist dieses Feature schon vorhanden.
Siehe Code:

class test// this class show the const-Feature in C++
{
private:       
       int value;// a test-value
public:
       test (int newValue)
       {
              value=newValue; // if the object is const, value can't has another value
       }
       int getValue () const // das ist die const-Signatur
       {
             return value;
 //          value = 5; // this is a compiler-error
//           setValue (5);// const method's can't call not-const method's
       }
       void setValue (int newValue) // this method can't call from const objects
       {
              value=newValue;
       }
};

PS: Nun rückt mal raus. Wie würdet ihr const und goto belegen.:reflect:

 

[maki]

Wie würdet ihr sie belegen?

Gar nicht.

Oder willst du etwa deine eigene Javaversion haben (deine Quelltexte würden nur bei dir laufen)?

 

[bygones]

PS: Nun rückt mal raus. Wie würdet ihr const und goto belegen.:reflect:

gar nicht - v.a. nicht goto - gehört nicht rein

ich finde sogar continue und break sollten verboten werden

 

[codingfriend]

Maki, das war doch nur ne Frage bzw.
schlichte Neugier was anderen so an Java fehlt oder
hast du das PS in dem 1. Post zu ernst genommen.
Ich werde nicht den Quelltext von Java verändern,
schon allein zwecks Plattformunabhängigkeit.

Du kannst es auch als Wunschliste für die
nächste Version auffassen.

Aber garnicht ist natürlich auch eine Antwort,
obwohl ich mir nicht vorstellen kann das dir garnichts an Java fehlt.???:L

Edit: Da ist mir wohl jemand zuvorgekommen.
Bei break und continue finde ich den Nutzen der Sprungfunktion auch fragwürdig.

 

[maki]

Hab wohl die Ironie im PS übersehen
const & vor allem goto brauche ich nicht bzw. die fehlen mir ganz sicher nicht.

Was sonst so fehlt wurde hier schon oft diskutiert, haben da den einen oder anderen Megathread zu diesem Thema ("Ist Java ein Dinosaurier?"), denke nicht dass es Sinn ergibt das in diesem Thread alles zu wiederholen.

 

[codingfriend]

Hallo Maki und die anderen, da hast du Recht,
obwohl es meiner Meinung nach in "Ist Java ein Dinosaurier?" darum geht,
ob andere Sprachen Java vorraus sind.
OK, ist nur'n kleiner Unterschied und mit const und
dem Vorhandensein in C++ bin ich dem ja schon nahe gekommen.

 

[Illuvatar]

Ich hab ne Idee für goto: wenn der Compiler das Schlüsselwort findet, fängt er an die Festplatte zu formatieren

 

[faetzminator]

ich finde sogar continue und break sollten verboten werden

Naja, [c]break[/c] brauche ich in [c]switch[/c] Statements und ich würde ungern [c]break[/c] verlieren und aus jedem Case automatisch rausfallen (, in welchen [c]break[/c] nicht geschrieben wurde)

 

[maki]

Naja, [c]break[/c] brauche ich in [c]switch[/c] Statements und ich würde ungern [c]break[/c] verlieren und aus jedem Case automatisch rausfallen (, in welchen [c]break[/c] nicht geschrieben wurde)

Ein [c]return[/c] wäre 'ne Alternative

 

[faetzminator]

Und jedes switch ohne Ausnahme in eine eigene Methode auslagern? Naja, würd mich damit abfinden

 

[Gonzo17]

Ein [c]return[/c] wäre 'ne Alternative

Aber haut dich ein

return

nicht gleich aus der ganzen Methode, statt nur aus dem switch? Genauso bei einer for-Schleife, da sind

break

und

continue

doch sehr hilfreich.

 

[maki]

Und jedes switch ohne Ausnahme in eine eigene Methode auslagern? Naja, würd mich damit abfinden

Wird sowieso empfohlen

 

[MrWhite]

Wer will mir hier continue und break wegnehmen?

Seien wir mal nicht päpstlicher als der Papst. Pragmatismus ist besser als übertriebene Code-Sauberkeit.

Geht zurück in eure Elfenbeintürme, ihr Möchtegern-Dijkstras.