ElkArte Community Modern, Free, Powerful
Community building forum software

Opening the minimum required PHP version for discussion.

We got a little carried away on the external API, and along with XML, we sort-of went for an introduction of JSON support in Elk core.
Reference: http://www.elkarte.net/index.php?topic=35.msg2221#msg2221

TBH, I don't think JSON as API "equivalent" with ajax requests is really of much use. I could be proven wrong, but what I would expect from a JSON output support in core, is to format and make available data to clients, such as provide news on the forum, or topics, or generally content. We'd probably have instead of this basic JSON "just output this as json" (example in the PR),  actual action handlers for json, to grab various (more) data for the consumer and send it over.

Regardless of it, though, json requires PHP 5.2, and Elk current documented support is 5.1+.

I would like to know what we think of changing the PHP required version to 5.2. Even without the small start over there (which we'll probably undo at rebase/merge), what is the minimum requirement we are comfortable with, and why?
Or, what are the client scenarios you want to have for a forum/site?

Further ref: http://www.elkarte.net/index.php?topic=134.msg2331#msg2331

json_encode might be minimum PHP 5.2 but as WordPress discovered to their horror, it's not actually enabled by default in a surprising number of hosts even on 5.2+... They had to release a patch because of how many systems refused to run WP properly after that.

So if you're bumping to 5.2 just for json_encode, it's not really enough of a reason, because you're still going to need a fallback anyway for those hosts idiotic enough to disable it.

Are there any other reasons you want to bump to 5.2 for? See, were this discussion over bumping to 5.3, there are legitimate improvements in the core OO model - late static binding - that would likely be useful to you in your quest to refactor SMF into an Elk-OO world. But 5.2? I can't think of a single reason other than json_encode to bump for, and even then...

Related question: are you still using the ISO/UTF-8 split? json_encode no likey ISO-anything.

5.2 is like 6 years old IIRC.  5.1 is about 8 I think.  I'd love to see us on 5.3, but that's me. I'm not much for giving much thought into how the people with crap hosts who don't update are affected.

To answer the questions:
No, there are no other reasons for 5.2. It has reached EOL already, so we're not even talking PHP support. (and that's an argument to move out from it in a sense).
Elk is UTF-8 only.

On 5.3 and late static bindings.
Well, I think we might already have a case or two or close, where we could ask ourselves about using late static binding, if it were available. But from my perspective, that wouldn't be a reason either (at all), because it's more of an implementation detail than an actual OO model improvement. (For PHP language, I mean. For the PHP applications, it affects design, but in very particular cases.) The classical OOP paradigm, which doesn't have late static binding, is IMO perfectly fine to design and write applications in. That's the essence of an OO model anyway.

And anyway we're not talking heavy OO in Elk either.
Even, for now we barely use sub-classing and instance methods overriding, in our design.[1] If we state we'd miss what amounts to static methods overriding, that'd be kinda, mmm, much. 

Perhaps it's just me being traditionalist, but seriously. I don't see the need for corner-case language features, when there's an unexplored world there in the OO paradigm and design patterns, on the basis of which we can and do rewrite this codebase. Moreover, even that, is trying to keep things simple, keeps procedural approach for a particular bunch of stuffs, lets things be.[2]

That said, the above were comments only on late static binding, not on 5.3.
Sorry for the probable derail off-track here. There's more about 5.3 worth taking into account.

---

[1] We should take advantage of object orientation. Just saying we mostly don't, yet.
[2] i.e. I don't really think .subs will see much object oriented implementations except for its xml_arrays or the like. And templates for sure nope. Routing yes, and it is. Controllers yes, and they are, and they should have interface implementation or class inheritance. etc. /just a side note.

Consideration (doesn't mean I want to use json, etc.): the fact we have for example json_encode in "core" doesn't necessarily mean we are not supporting php 5.1.
For example in this case, the json_encode was added to the core, but in fact its output was not used at all by anything in the core. It's just there "for convenience", if a mod wants to use it. In my (current, may be in a couple of days I could change idea ), we are still supporting php 5.1 because all Elk's features work out-of-the-box on php 5.1.

Yes, I know, something like that would be messy...

I think we decided 5.2 is not worth at the moment.

Yeah .. I think it was more of a 5.2 is a meh, so we either stay 5.1 and the next move is 5.3 (or .4?)

5.2 has a lot of cool additions I use in Wedge. Mostly extra params to useful functions. I'd never go back to 5.1. As for 5.3 I'd rather wait for 5.4 and its [] definitions. Although, anonymous functions, way to go... I take that back, eheh.