[Discussion] "Hello World" Redux (towards a possible Plugin SDK)

[Angryboy]

I would even argue it doesn't do this completely.

Fair enough (I have to concede the same).

Yes, and this is much a matter of target audience. What is the level of skills of aspiring plugin developers? For me, it was zero. The only thing I knew about PHP was how to build forms & some other really basic stuff. And when you look at the code for WJ Notepad or some other plugins, you'll see it's pretty "low quality" (in terms of design patterns).

And although I would never use plugins like File editor, DY Lorem Ipsum or I18n language Menu Ex (because what these plugins do is so basic and offers, imo, no substantial benefit over hand-coding/ copy-pasting), it would be overkill to request from plugin authors that they become familiar with classes and OOP for such simple plugins, certainly when they start from zero (I learned more quickly because I already had an OOP/MVVM background in JS).

On the other hand, if I could I would totally urge plugin authors to build plugins which offer something substantial; I mean, plugins which truly save you a lot of effort (but ofc. also require more effort from the dev) eg. I18N, Itemmanager, Newsmanager (to name the truly biggest ones).
Same for custom functions, eg. I don't think $this->register(array(...)) is much more advantageous than register_plugin(...).

Ideally, I think, there would be a 'Hello World' basic example, an intermediate, and an advanced example, perhaps we could even make use of the popular TodoMVC structure for the advanced example. This thread's initiative would be fit for the second/ third one.

I also came in at next to 0 real programing experience besides very simple PHP scripts, and have largely picked things up since studying Computer Science, so I completely understand the "void" of sorts between the example plugin and the useful ones developed by our popular authors.

Fitting the 2nd/3rd description seems fine to me, then. From what I have seen, structuring a non-trivial plugin without any kind of OOP structure is like pulling teeth. When people make requests for the plugin's features later down the line, you get feature-creep, and it becomes insanely difficult to manage the growth of the codebase without encapsulating certain procedures into classes/singletons. On the flipside, I'd been hoping to allow the GSPlugin class to let users still benefit from OOP wrappers without having to implement them themselves (e.g. linking to other PHP scripts for procedures to execute, rather than having to create a global function or create their own class methods). Again, this is all experimental, so if it seems like a bad idea I am willing to scrap it.