CommandFramework3 #94
@ -44,21 +44,21 @@ public class TestCommand extends SWCommand {
|
||||
// Another Command, subCommands can be implemented with the Register Annotation,
|
||||
// you can use custom Mappers by putting a Mapper Annotation on a Parameter
|
||||
@Register({"two"})
|
||||
public void testTwo(Player player, int i, @Mapper("Hello World") Material material) {
|
||||
public void testTwo(Player player, int i, @Mapper("solidMaterial") Material material) {
|
||||
|
||||
}
|
||||
|
||||
// Add Custom Mapper when this command is registered, all Mapper of you class will be
|
||||
// created first and than the Commands. Do not use this mapper outside your class, as
|
||||
// it can only create failures. Use on your own risk. Definition order should be considered.
|
||||
|
||||
@Mapper("Hello World")
|
||||
@Mapper("solidMaterial")
|
||||
public TypeMapper<Material> materialTypeMapper() {
|
||||
Lixfel
hat
Das das ganze mit Strings funktioniert, gefällt mir immer noch nicht (und dir wsl. auch nicht). Da anscheinend keine Interfaces, sondern nur konkrete Instanzen einer Klasse verwendet werden können: Mach doch eine Klasse TypeMapper, die als Parameter eine Funktion String -> Objekt nimmt. Dann ist das eine klare Klasse. Ggf. ist das dann erstmal ein Object (wenn Templating nicht geht) ansonsten spricht aber meines Wissens nach nix dagegen, oder? Das das ganze mit Strings funktioniert, gefällt mir immer noch nicht (und dir wsl. auch nicht). Da anscheinend keine Interfaces, sondern nur konkrete Instanzen einer Klasse verwendet werden können: Mach doch eine Klasse TypeMapper, die als Parameter eine Funktion String -> Objekt nimmt. Dann ist das eine klare Klasse. Ggf. ist das dann erstmal ein Object (wenn Templating nicht geht) ansonsten spricht aber meines Wissens nach nix dagegen, oder?
YoyoNow
hat
Ich verstehe dein Vorschlag nicht ganz. Du willst, dass ich in der Annotation eine Object angebe, welches dann eine Function<String, Object> beinhaltet. Wie soll das das Mapper zeug lösen. Kannst du versuchen das nochmal etwas genauer zu beschreiben? Ich verstehe dein Vorschlag nicht ganz. Du willst, dass ich in der Annotation eine Object angebe, welches dann eine Function\<String, Object> beinhaltet. Wie soll das das Mapper zeug lösen. Kannst du versuchen das nochmal etwas genauer zu beschreiben?
YoyoNow
hat
Das hier spricht dagegen (Allowed Types in Annotation):
Multidimensional arrays are forbidden. Arrays of type Class are forbidden. Hier warum letzteres verboten ist: 'Constant Expressions' ist das Stichwort ![image](/devlabs/attachments/3c90a023-f8d5-4ba7-827e-473af354ade4)
Das hier spricht dagegen (Allowed Types in Annotation):
- primitive
- String
- an Enum
- another Annotation
- Class
- an Array of the above
Multidimensional arrays are forbidden. Arrays of type Class are forbidden.
Hier warum letzteres verboten ist:
![image](/devlabs/attachments/2081e223-2da1-4f23-96ca-2cd5b0101bd7)
'Constant Expressions' ist das Stichwort
|
||||
List<String> tabCompletes = Arrays.stream(Material.values())
|
||||
.filter(Material::isSolid)
|
||||
.map(Material::name)
|
||||
.map(String::toLowerCase)
|
||||
.collect(Collectors.toList());
|
||||
return new TypeMapper<>() {
|
||||
return new TypeMapper<Material>() {
|
||||
@Override
|
||||
public Material map(String s) {
|
||||
return Material.valueOf(s.toUpperCase());
|
||||
|
Liest sich arg hacky, ich fände es gut, wenn Mapperobjekte nur einmal erstellt werden und ggf. von mehreren Befehlen genutzt werden könnten. Evtl. eine Annotation @Mapper mit einem TypeMapper als Argument statt einem String? Dann haben wir auch nicht mehr die dreckige string-lösung.
Ich wollte die Mapper explizit von dem Parameter weghaben, damit diese explizit auch global erzeugt werden können. Das was du da liest ist eine abkürzung, womit du Mapper, welche du nur hier in diesem Befehl brauchst hier definierst und verwendest. Ab dem Moment wird es für alle Befehle, welche danach erzeugt werden auch existieren. Der String ist explizit, damit man ein Argument 'Material' haben kann, welches jedoch einen anderen Mapper haben kann. Der name ist dann auch so gut zu wählen wie nötig oder möglich.
Die Mapper an sich werden auch nur einmal erzeugt und dann in eine Map intern gepackt. Außerdem kann man in Annotationen keine Interfaces als fields verwenden:
Deswegen geht deine Idee leider nicht, hatte ich auch schon als Idee.