Hello plugin developers! Some of you will remember the old way of creating plugins on a single file. It might come back... In a different way. Sometimes you want to test an idea or just hook into a single event, but you don't so because writing a new plugin is a long and tedious task (lazy guy >.<). Well, we're working on a new single-file plugin format to write simple scripts. There are drawbacks, as well. You can't have embedded resources or complex types in the descriptor part (example, arrays for authors). Also, all the code is saved in clear-text, and you won't be able to submit it as a plugin on the repository. This is not a replacement for the current format, it's just an addition. You can see the auto-documenting example on a Gist Please check it out and give feedback. This is not final in any means, it's just the first draft.
Would be good for old API Developers, but not that good for new ones. In my opinion, a nice addition if both ways can be used.
Remember, you can't release the single-file plugin. This is only for fast server scripting by the end-user or prototyping. So "Old API" developers still need to do the same as on normal plugins (syntax is equal) except that you can do everything on a single file.
This thing has nothing to do with the old API at all. The API is just still the new API. It is plainly 1.4+ plugins having all files merged into one with a slightly different manifest format.
Well really, all that is needed to implement this, is checking if a class exists before calling the autoloader and checking if the plugin has annotated plugin descriptors. Really with PocketMine's autoloader, there is absolutely no reason to prefer single-file plugins because that would be pretty much concatenating multiple files into one without any meaningful difference in syntax, features or simplicity. But if one is so keen on having the plugin in a single file, this seems like a good middle ground!
@sekjun9878 As specified in the post, this is not for normal plugin development, only fast scripting and/or testing. You won't be able to publish this plugin and it also has some drawbacks that make it non-useful for normal development.
Load it like that. This is not a way for making proper plugins. Plugins will not be accepted if you do that.
I think a good question would be more around how to select whether or not to enable the system/how to actually use it. For example: Would debug have to be enabled for the server in order to use these snippets? Would you just drop the file into the plugins/ folder, or is it a different location? Also, what other features could be included with this? (i.e. autoreload on file change?) Overall, it would beat having to use DevTools to load a skeleton and modify it
Setting the debug level is a good idea, I might do that with devtools as well. It would just be dropped in plugins/ as a .php file, so it won't collide with source plugins. Reload is still impossible (can't unload declared classes)
By reload i meant restart the server, but i see how that could be undesirable. Other than that, sounds good!
It's great when i got an idea i need to make new plugin just to test few line codes and thats so anoying >.<, but this is da perfect solution Huraay.
