New module conventions

[ceford]

In a recent post it was pointed out that all of the existing tutorials on how to author a module are
using old conventions with single entry file and mod_quickicon is so far the only core module to use new conventions.

I wrecklessly offered to update the documentation but now have cold feet. I think that new conventions means using Dependency Injection and that seems simple enough to do. Understanding it is another matter. Is it worth it for modules? Will old methods work forever anyway? Should we encourage developers to use DI for modules? Is there an example case where DI would be distinctly better - I have stepped through the QuickIcon code without seeing exactly where it is better.

So far, all I could do would be create a new tutorial explaining how Quickicon works as an example of the new conventions.

References:
The recent post referred to: viewtopic.php?f=803&t=988384
Dependency Injection in Joomla 4: https://docs.joomla.org/J4.x:Dependency ... n_Joomla_4
Why dependency injection: https://github.com/joomla-framework/di/ ... jection.md

[sozzled]

Aside from achieving something that's possibly "wreckless" (as opposed to doing something recklessly), I have mixed views that depend on whether I'm starting a new software project or whether I'm updating something—just to get it to function—because something else within the software environment has changed.

J! 4 (which isn't a whole lot different to J! 3.10 as far as the APIs are concerned) is earth-shatteringly different to J! 3.0 (or most versions earlier than J! 3.8 ). J! 3.8.0 was released a little over three years ago, but I started building my extensions at least five years before that; in my case I was building these things by applying the monkey-see-monkey-do principle.

One of many problems confronting ordinary folk—who are just looking for something to plug into their J! 3.10 or J! 4.0 website—is the absence of truly compatible extensions that adopt the new coding conventions/paradigms). Underlying this issue is that the great majority of extensions listed on the JED are crap, from a software design point-of-view. That's not to say that these extensions don't work. Far from it. I'm just saying that, from a purist perspective, most of the extensions that exist on the JED are written "badly".

One could say that the quality of "code-penmanship" in the JED has always left a lot to be desired.

I consider myself no better than anyone else; I've written some terrible code in my lifetime. For example, many of my extensions continue to have jimport references (instead of use namespace) or they rely JString and JFactory, and so on. One change I have made is to eliminate isAdmin() and isClient()

But so what? Does it matter if extensions use outdated coding conventions? Not really; as long as they work and as long as the JED people don't wipe perfectly reasonable extensions from the directory because they weren't "rittin ryte" (deliberately misspelled to make the point).

@ceford: you've done great work. I don't understand some of the arcane technical issues but your tutorials are helpful to those who may need them. I wouldn't lose too much sleep over this. Better still, now that George Wilson is probably at a loose end, why not press-gang him into helping you co-author the docs? Cheers.