SteamWar/SpigotCore
Archiviert
13
0

CommandFramework3 #94

Manuell gemergt
Zeanon hat 71 Commits von CommandFramework3 nach master 2021-03-30 21:15:40 +02:00 zusammengeführt
Nur Änderungen aus Commit 57b5c2b81b werden angezeigt - Alle Commits anzeigen

Datei anzeigen

@ -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.
Veraltet
Review

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.

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.
Veraltet
Review

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:
image
Deswegen geht deine Idee leider nicht, hatte ich auch schon als Idee.

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: ![image](/devlabs/attachments/7bc5f00b-475e-4314-bdd1-7fc6a4dbe5f0) Deswegen geht deine Idee leider nicht, hatte ich auch schon als Idee.
@Mapper("Hello World")
@Mapper("solidMaterial")
public TypeMapper<Material> materialTypeMapper() {
Review

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?
Review

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?
Review

image

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

'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());