Version 5.0

[Wundero]

This is my sort of idea list for version 5 that I would like to put out before working on it. Figured this time it would be better to make the complete update process transparent as migrating from 3 to 4 was quite interesting.

I have two streams, with separate ideas, that can be implemented:

• [ ] Multiple @Token parameters in a method, parsed out as _ separated in order from left to right
  • [ ] Support lists/arrays as a "parse till you fail" style approach
  • [ ] String lists/arrays not allowed unless at the end of the param list
  • [ ] If final param is string and multiple token parts remain to parse, stick them in
  • [ ] Support for having middle parameters be @Nullable -> if parsing fails, try parsing to the next parameter from the same token
  • [ ] Class transformation to make small array types (like int[] or String[] with an expected size of 2 or 3) into separate parameters
  • [ ] Token parsing priority? (for instance, if tokens can be %a_b_c% or %a_b_d_5% and you put priority on 5, it will try to parse out that situation first) -> may not be worth it since it adds a layer of complexity.
• [ ] Multiple methods under the same id using different token configurations
• [ ] Custom, per placeholder token parsers attached to a specific parameter.

OR

• [ ] Replace placeholder system with the Cause and Context system?
  • [ ] Throw an event when starting to parse a placeholder
  • [ ] Cause would contain sender, observer, and all parsed values from the token
  • [ ] Use command system (ValueParser, Parameter, etc.) to parse a placeholder's tokens
  • [ ] Event would contain:
  • placeholder id
  • a list of parsed token objects
  • the raw placeholder
  • the selected placeholder that will be used to parse
  • a cancellation boolean
  • [ ] If parsing fails, throw out an event for getting the error message + suggestions
• [ ] Support an asynchronous event chain for the above AS WELL AS async/sync placeholder distinction
  • [ ] In placeholder declaration, define support for this (as in, @Async or something)
• [ ] Placeholder method refactor:
  • Something like the following code block
  • Cause support (I'm not 100% sure about how causes work/will work, so if causes can support storing all the data needed, there will be no need for the object
  • If needed, some kind of object representing: the raw placeholder string, the parsed tokens as objects, the source, and the observer
  • Event filter parameters + a bit extra for support for this

    @Placeholder("example")
    @Async
    public Object example(ParsedPlaceholder placeholder, Cause cause, @First Player source, ...) {
    /*...*/
    }

    As well as those two streams, there would be some common ground:

• [ ] Sponge API 8 required (adapt commands + events to it)
• [ ] Proper events -> throw events (advanced check to see if attaching plugins use events??? -> save performance to not throw them if no one cares)
• [ ] Placeholder attaching: that is, an object attached to any object that can be a source for placeholders.
  • Methods would be refactored to not include source objects (as they are attached to the object), rather supporting a field representing the attached object
  • Use injection to do construction???
  • Parse against attached placeholders first; saves some performance.
  • Unattached placeholders attach to Sponge server???
• [ ] Attach to Sponge internals:
  • [ ] Register builders to the Sponge registry
  • [ ] Better listener support
• [ ] Better error handling for placeholders
• [ ] Data API support within the Sponge API
• [ ] Better Placeholder formatting:
  • There needs to be a better way of parsing and determining placeholders than is currently implemented. Some ideas:
  • [ ] Better regular expression support. The current support only works if the placeholder is contained within group 1. I might try to make a better system for this, where patterns attached to methods are given a group where placeholders exist, but I prefer:
  • [ ] Replace the regular expression system altogether with another parser. This parser would be more systematic and targeted to the plugin. This would also help simplify placeholder id finding, etc. This would look something like: {id:player,type:name}
  • The latter would quite help with token parsing, as well as having direct mappings instead of conditional logic (so type:name for id:player would directly correspond to a function getName in this case).

That's all I've got for now but it's pretty big so I will leave it as is. for a bit. Any suggestions are appreciated, as always

[Wundero]

So I've been playing with the idea of the parser system, and I've come up with some ideas:

• Use regex on %...% placeholders and json/hocon on {...} placeholders
• Regex style will be unchanged
• In json, no tags specified (like {player}) would parse as if that was the id (like {id:player})
• Placeholders can register default values for certain tags (id being the only non-optional enforced tag), which will be null otherwise (if they register it as non-optional, just don't call placeholder parsing method)
• Shorthand support (type shortens to t, etc. If there are 2 or more parts that start with the same letter, shorthand would be disabled)
• Placeholder builder would work like commands, giving children and such, with arguments and defs, as well as giving minimum type for Source and Observer, if Source or Observer is necessary, executors, etc.
• Parameters for the parent of a child could still be applied to the child?
• Support value modifiers before and after parsing? (Such as latin-text or prepend/append spaces running after, or changing source before)
• For placeholder dynamic method registration, support all-encompassing methods and use class-writing to split it up????
  • This could prove to be quite the challenge, however if the methods are simple like just using switch statements, this could be quite useful.
• Have class be placeholder id, with methods, default value method, etc.

I still need to figure out how this system might include support for placeholder-object attachment.

[ronaldburns]

I like the Cause and Context system because it's what I already know when learning Sponge. I've read over your first idea a couple times now and I still can't wrap my head around it.

[Wundero]

It's likely that I will adopt something like that, though I think using contexts in some way is more important since they are named. If there is no source but an observer exists, the placeholder may think the observer is the source (which may or may not be desirable), so I have to do some thinking about what to do.

[Wundero]

Oops clicked the wrong button.

[ronaldburns]

I've read through this many times now and am still confused. Won't be able to help out until I see some commits as a start. :(

[Wundero]

I am still figuring out how I want to go about making this update as there are a lot of things that would have to be changed, and if I should wait until 8.0 hits a snapshot stream to start or just force 7.0 instead. I will create commits at some point which lay out the groundwork but I have some thinking to do first haha. I was on holiday and so had no time to work on this the past couple of weeks, but I might be able to get some things done soon (I hope).

[Wundero]

Another rough idea I have: I would like to create an asynchronous handling system for placeholders; that way, if a placeholder takes a long time to parse (for instance a mysql query), it does not slow the main thread. Ideally, all placeholders should be asynchronous since they are not supposed to modify any Sponge objects, and thus asynchronous computation is fine (we do not care about values that may change during execution, since we will only be grabbing it once anyways), however placeholders like the sound placeholder may not support it. If a placeholder does not support asynchronous computation, it will be parsed synchronously and then wait for the remaining async parses to complete. Realistically, if I handle this properly, there should be no issues with having parts be synchronous and parts not, due to the fact that parsing is the only real external handling and each parser should be independent. The javascript parser may present an issue if called async and that worries me, so what I might do is use the classwriter from ASM to determine if calls are made to the placeholder service parsing, and if they are enforce that that placeholder is synchronous.

CompletableFuture should allow me to do most of this properly, and I will probably use something like a ResultBuilder that supports concurrent modification (with a concurrent hash map probably) to combine the results and then return them.