Typedefs in Java?

[Sascha Laurent]

Ich beziehe mich hier nochmal indirekt auf

http://www.java-forum.org/java-basics-anfaenger-themen/97828-welche-collection.html#post622037

In C++ kann man z.B. auch dazu benutzen, um integers einem Eigenständigen Namen zu geben. Ich habe nochmal gegoogelt habe aber nichts passendes gefunden.

z.B.
typdef myint int;

private class myint extends Integer

ist z.B. nicht möglich, da Integer als final deklariert ist.

Danke
Sascha

Bevor jetzt aber wieder ein Frage kommt, wie "wozu brauchst du das denn?" :autsch:ueh:
Es ist manchmal ganz sinnvoll eigene Datentypen zum besseren Lesen zu Verwenden.
Außerdem ist es manchmal auch ganz sinnvoll einen selbstbeschriebenen Datentyp zu verwenden, wenn dieser zu einem späteren Zeitpunkt einfach ausgetauscht werden soll.

 

[André Uhres]

Es ist manchmal ganz sinnvoll eigene Datentypen zum besseren Lesen zu Verwenden.
Außerdem ist es manchmal auch ganz sinnvoll einen selbstbeschriebenen Datentyp zu verwenden, wenn dieser zu einem späteren Zeitpunkt einfach ausgetauscht werden soll.

Wozu brauchst du das denn?
"myint" liest sich jedenfalls nicht besser als "int" und ohne gemeinsame Schnittstelle kann man eh keine Datentypen später "einfach austauschen".

 

[Marco13]

Bei der Antwort aus dem verlinkten Thread

public class NameMap extends HashMap<List<String>> { }

Hat's mich kurz geschaudert. Eigentlich sollte man IMHO nicht eine Klasse in dieser Form anlegen. Einerseits ist der Wunsch danach schon nachvollziehbar. Spätestens wenn man eine

private Map<List<? extends Comparable>, Set<List<? super List<? extends Number>>> freakyMap;

hat, könnte man versucht sein, das mit so einem "Pseudo-Typedef" zu einer einfachen Klasse "FreakyMap" zusammenzufassen. Aber für mich ist das unschön, weil es keine private Vererbung (wie in C++) gibt. Außer durch (ggf. aufwändige) Delegation kann man das kaum umgehen. Zumindest theoretisch etwas sauberer wäre dann sowas wie

interface FreakyMap extends Map<List<? extends Comparable>, Set<List<? super List<? extends Number>>> { }

class HashFreakyMap extends HashMap<...> implements FreakyMap<...> { }

aber ... naja - alles hat seine Grenzen. Es könnte aber Fälle geben, wo das gerechtfertigt ist - zumindest bei statischen inneren/package private Klassen ist ja alles erlaubt

 

[Sascha Laurent]

Wozu brauchst du das denn?
"myint" liest sich jedenfalls nicht besser als "int" und ohne gemeinsame Schnittstelle kann man eh keine Datentypen später "einfach austauschen".

Wozu brauchst du das denn? :shock:

 

[Noctarius]

Bei der Antwort aus dem verlinkten Thread ... Hat's mich kurz geschaudert.

Hab ja auch nicht gesagt, dass man das machen soll, es war aber genau die Antwort auf die Frage die er gestellt hat.

 

[André Uhres]

Wozu brauchst du das denn? :shock:

Tut mir Leid, dass du wegen mir einen Schock erleiden musstest .

Aber jetzt ernsthaft: so sehr ich auch über deine Argumente nachdenke und versuche, mir das an einem konkreten Fall vorzustellen, ich komm einfach nicht dahinter, wozu man das braucht. Darum lass ich die Frage noch im Raum stehen: Wozu brauchst du das denn?

 

[thE_29]

Also da ich in letzter Zeit mehr C++ als Java mache, finde ich die schon recht toll
Manchmal bißchen verwirrend, da man dann nach 5 Verweisen draufkommt das isn ganz normaler String oder int aber der Typ heißt zB SATCHANNEL.
In der WinApi hat das MS eigentlich fast überall gemacht.. Aber unter Java kenne ich sowas nicht..
Ableiten ist ja nicht das gleiche und geht ja bei final Klassen sowieso nicht..

 

[maki]

Bevor jetzt aber wieder ein Frage kommt, wie "wozu brauchst du das denn?"

Wozu brauchst du das denn??
Meine ich ernst, ist doch vollkommen überflüssig in Java.

Es ist manchmal ganz sinnvoll eigene Datentypen zum besseren Lesen zu Verwenden.

Wenn du einen eigenen Datentypen hast, kannst du den ja benennen wie du möchtest.
Wenn du aber keinen eigenen Datentypen hast, wäre es doch nur verwirrend einem bestehenden Datentypen einen anderen Namen zu verpassen.

 

[Marco13]

Ist dieser Wunsch nicht legitim? ???:L

Einerseits ist der Wunsch danach schon nachvollziehbar. Spätestens wenn man eine

private Map<List<? extends Comparable>, Set<List<? super List<? extends Number>>> freakyMap;

hat, könnte man versucht sein, das mit so einem "Pseudo-Typedef" zu einer einfachen Klasse "FreakyMap" zusammenzufassen. Aber für mich ist das unschön, weil es keine private Vererbung (wie in C++) gibt.

(unabhängig davon, wie man es umsetzen sollte oder wie nicht - natürlich sollte das nur ein Extrembeispiel sein, dass man so in jedem fall NICHT umsetzen würde, aber grundsätzlich wird's eben spätestens bei verschachtelten Generics schnell unübersichtlich...)

 

[maki]

Ok, mit Generics könnte das schon Sinn machen

 

[kama]

Hallo,

typdef myint int;

Wenn schon dann richtig..

typedef int myint;

Aber in dem Zusammenhang macht das nicht wirklich sinn...

typedef char  Int8;
typedef short Int16;
typedef int   Int32;

Bei so etwas schon eher...Das ist dann das Thema wg. Plattformunabhängigkeit...

und noch mehr bei so etwas:

typedef int(*FunktionsZeiger)(double);

Aber das gibt es ja zum Glück in Java nicht ;-)

MfG
Karl Heinz Marbaise

 

[nettersurfer]

Ich brauche auch so was. Voll im ernst.
Zum Beispiel um bei einem Funktionsaufruf mehrere Parameter vom Typ String zu übergeben, die aber verschiedene Wertebereiche haben. kaufeSchuh(grösse, farbe) /* beide Parameter Strings */ dann könnte der Compiler feststellen, wenn die Argumente in der falschen Reihenfolge vorliegen.

 

[tfa]

Ich brauche auch so was. Voll im ernst.
Zum Beispiel um bei einem Funktionsaufruf mehrere Parameter vom Typ String zu übergeben, die aber verschiedene Wertebereiche haben. kaufeSchuh(grösse, farbe) /* beide Parameter Strings */ dann könnte der Compiler feststellen, wenn die Argumente in der falschen Reihenfolge vorliegen.

Dieses Problem könntest du eher mit Enums lösen.

 

[Firephoenix]

Oder wenn man es mit Strings macht wenigstens eine ordentliche Parametervalidierung mit entsprechender IllegalArgumentException - wenn man eine Methode falsch benutzt darf einem als Programmierer ruhig mal eine unchecked Exception bis nach ganz oben durchknallen, dafür sind die Dinger schließlich da.

(Für den Fall sind Enums aber tatsächlich schöner )

Gruß

 

[d3rbastl3r]

Ich brauche auch so was. Voll im ernst.
Zum Beispiel um bei einem Funktionsaufruf mehrere Parameter vom Typ String zu übergeben, die aber verschiedene Wertebereiche haben. kaufeSchuh(grösse, farbe) /* beide Parameter Strings */ dann könnte der Compiler feststellen, wenn die Argumente in der falschen Reihenfolge vorliegen.

Entweder wie tfa bereits sagte mit Enums, oder mit eigenen klassen

class Schuhgroesse{
    private String groesse;

    public Schuhgroesse(String groesse){
        this.groesse = groesse;
    }

    public String toString(){
        return this.groesse;
    }
}

class Schuhfarbe{
    private String farbe;

    public Schuhgroesse(String farbe){
        this.farbe= farbe;
    }

    public String toString(){
        return this.farbe;
    }
}

kaufeSchuh(
    new Schuhgroesse("grösse"),
    new Schuhfarbe("farbe")
);

 

[Jango]

z.B.
typdef myint int;

private class myint extends Integer

ist z.B. nicht möglich, da Integer als final deklariert ist.

Das Ganze macht meiner Meinung nach eh keinen Sinn, weil nach der Typdefinition 'myint' den Datentyp 'int' repräsentiert. Und ich hab noch nie gehört, dass man eine Klasse nach einem Datentyp benennen kann - das sind doch geschützte Wörter in einer Programmiersprache - oder irre ich mich hier?

 

[Antoras]

Das Thema ist zwar schon etwas älter, aber da ich finde, dass an der Fragestellung bisher ein wenig vorbei geredet wurde, muss ich dazu noch was posten.

Java hat keine Typsynonyme, das heißt deswegen aber nicht, dass sie nicht sinnvoll einsetzbar sind. Sie erlauben umfassende Möglichkeiten typsicher zu programmieren. Die einfachste Form wäre

type File = String

. Das birngt noch nicht viel außer ein wenig Dokumentation des benutzen Typs. Parametrisierte Typen mit einem Typalias zu versehen ist schon sinnvoller, da sie einfacher zu benutzen sind

type ValidationList<A, B> = Validation<List<A>, B>

. Typaliase existieren nur zur Compilezeit, d.h. sie kosten keinen Runtime-Overhead (im Gegensatz zu einer Subklasse, die man in Java dafür verwenden müsste). In Haskell gibt es noch das

newtype

Schlüsselwort, das verhindert, dass man Funktionsparameter falsch verwendet:

newtype ShoeSize = ShoeSize String
newtype ShoeColor = ShoeColor String
data Shoe = Shoe {size :: ShoeSize, color :: ShoeColor}

buyShoe :: ShoeSize -> ShoeColor -> Shoe
buyShoe = Shoe

buyShoe (ShoeSize "35") (ShoeColor "green")

Das kostet wieder kein Runtime Overhead, da die

newtype

zur Compilezeit wegoptimiert wird. Kann man in Java prinzipiell mit Enums auch erreichen, aber halt eben nur mit Runtime Overhead.

Und ich hab noch nie gehört, dass man eine Klasse nach einem Datentyp benennen kann - das sind doch geschützte Wörter in einer Programmiersprache - oder irre ich mich hier?

In Java ist ein

class Integer {}

gültig, aber kein

class int {}

. Das ist unschön, aber tatsächlich nur auf Sprachen begrenzt, die zwischen Objekten und primitiven Datentypen im Typsystem unterscheiden. In Haskell oder Scala wäre ein

type Int = String

(was wie gesagt keiner Vererbung entspricht) ohne Probleme möglich, warum sollte es auch nicht gehen? Kann der Compiler wieder alles wegoptimieren sodass kein Runtime Overhead entsteht (wobei das Beispiel natürlich dämlich ist).

wenn man eine Methode falsch benutzt darf einem als Programmierer ruhig mal eine unchecked Exception bis nach ganz oben durchknallen, dafür sind die Dinger schließlich da.

Warum sollte der Fehler erst zur Laufzeit erscheinen, wenn er auch vom Compiler gefunden werden kann? In Haskell wäre es unmöglich die oben gezeigte [c]buyShoe[/c] Funktion falsch aufzurufen. In Java hätte man ähnliche Typsicherheit mit enums auch, nur benutzt das so niemand. Ein

Shoe buyShoe(ShoeSize size, ShoeColor color)

findet man selten, eher

Shoe buyShoe(String size, String color)

. Wenn man da die Parameter vertauscht hat der Compiler keine Chance den Fehler zu finden. In Haskell würde niemand

buyShoe :: String -> String -> Shoe

schreiben (außer Anfänger).

Typsicherheit ist unglaublich wichtig - warum sonst sollten statisch typisierte Programmiersprachen existieren. Javas löchrige Typsystem ist aber kein Argument dafür Typsicherheit wieder unnötig aufzugeben.

 

[Noctarius]

Und ich hab noch nie gehört, dass man eine Klasse nach einem Datentyp benennen kann - das sind doch geschützte Wörter in einer Programmiersprache - oder irre ich mich hier?

Innerhalb der Sprache Java ist das tatsächlich absolut richtig. Im Bytecode könnte man solche Dinge allerdings umsetzen. Die JVM Spec ist in Sachen Bezeichner um einiges liberaler als die Programmiersprache

 

[hüteüberhüte]

Es ist manchmal ganz sinnvoll eigene Datentypen zum besseren Lesen zu Verwenden.

Blödsinn! Halt dich an die vorhandenen primitiven Datentypen, wenn du möchtest, dass dein Code auch von anderen gelesen werden kann.

Viel Spaß mit C :lol:

 

[gasssst]

Blödsinn! Halt dich an die vorhandenen primitiven Datentypen, wenn du möchtest, dass dein Code auch von anderen gelesen werden kann.

Viel Spaß mit C :lol:

Ah, das wird aber schwer werden in Java so ganz ohne Klassen zu programmieren.

Troll dich...

 

[Jango]

Ah, das wird aber schwer werden in Java so ganz ohne Klassen zu programmieren.

Kapier ich nicht...

Troll dich...

Das unterschreibe ich...

 

[hüteüberhüte]

Ah, das wird aber schwer werden in Java so ganz ohne Klassen zu programmieren.

Troll dich...

Verpiss dich

 

[Noctarius]

@gassst
Aber wieso sollte man einen int als dword, handle, ... bezeichnen wenn man bei int weiß "ja es ist 32bit und fertig".

und @hüteüberhüte:
Bitte etwas mehr Umgangston. Es besteht ein kleiner Unterschied zwischen "troll dich" und "verpiss dich" - Danke

 

[hüteüberhüte]

[OT]Entschuldigung - Aber - ich wurde auch angetrollt. Der Umgangston war aber dennoch nicht i.O. Löscht meinen Beitrag am besten wieder, ich kann ihn jetzt nicht mehr editieren. And if i must be cautioned, auch Ok[/OT]