"loadColumn" why?

[Krileon]

Why was "loadColumn" changed from "loadResultArray" without backwards support. What justifies this change? It purely routes to fetchArray, which calls TYPE_fetch_array. "loadColumn" makes no sense in the scope of its usage while "loadResultArray" is completely logical as it is fetching the result as an array. This literally breaks thousands of extensions that are utilizing "loadResultArray" as there isn't even backwards compatibility for it.

To further solidify that the new name makes no sense please review the phpDoc for the very function as follows.

"Method to get an array of values from the <var>$offset</var> field in each row of the result set from the database query."

So far my experience with Joomla 3.0 has been primarily visual and am quite impressed with that leap, but API wise there is so much "change for sake of change". I can't make sense of some of these depreciation's as they purely don't make any. Please explain.

[tampe125]

Welcome to the club!
Did you ever tried to create a component compatible with J1.5 and J2.5?
You'll see tons of these examples: quoteName became nameQuote, authorise became authorize and so on...

[Andrew Eddie]

On Saturday, 22 September 2012 04:35:48 UTC+10, Krileon wrote:

Why was "loadColumn" changed from "loadResultArray" without backwards support. What justifies this change?

The name better reflects the purpose of the method.  "Column" is a familiar term in database terminology.  "Result array" is fairly ambiguous.

 

It purely routes to fetchArray, which calls TYPE_fetch_array.

Correct.  That's the appropriate PHP API to use for the method.

 

"loadColumn" makes no sense in the scope of its usage while "loadResultArray" is completely logical as it is fetching the result as an array.

As I said, "column" has a familiar meaning in database terminology whereas "result array" could mean any type of result as an array (loadObjectList can technically be considered an array of results).

 

This literally breaks thousands of extensions that are utilizing "loadResultArray" as there isn't even backwards compatibility for it.

Well, no, it doesn't break the extensions (necessarily) and there *is* backward compatibility.  The "loadResultArray" is clearly marked as deprecated in Joomla 2.5.7.  See https://github.com/joomla/joomla-cms/blob/2.5.7/libraries/joomla/database/database.php#L1835

As it happens, "loadColumn" is also available in 2.5.7.  Therefore, one can easily make an extension that is 2.5+3.0 compatible (using "loadCoumn") or 1.5+2.5 compatible (using "loadResultArray).  However, you cannot make an extension easily compatible with 1.5+2.5+3.0 - and in that scenario, "loadColumn" is the least of your worries.  There are many changes in 3.0 which make it extremely difficult to have extensions support from Joomla 1.5 through to 3.0 - this is but one of them.  What developers are basically going to have to do is probably produce a final 1.5 version of their extension plus a 2.5+3.0 version.  We've been very careful to actually not break backward compatibility just for the sake of it and certainly not without notice.

For more information about what extension developers need to be aware of, see:

http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_3.0_and_Joomla_Platform_12.1

 

To further solidify that the new name makes no sense please review the phpDoc for the very function as follows.

"Method to get an array of values from the <var>$offset</var> field in each row of the result set from the database query."

That sound like "get a column of results" to me.

 

So far my experience with Joomla 3.0 has been primarily visual and am quite impressed with that leap, but API wise there is so much "change for sake of change". I can't make sense of some of these depreciation's as they purely don't make any. Please explain.

These changes to the database drivers have been in for a very long time now and I can't recall anyone complaining about them previously.  If you have problems with other deprecations I'd be happy to respond with the thinking behind the change if you list them.  I can't guarantee you'll agree with the reasoning, but that doesn't not mean someone thought there was a logical basis for change, enough at least to have it accepted into the core.

Hope this helps.

Regards,

Andrew Eddie

[Andrew Eddie]

On Saturday, 22 September 2012 10:13:54 UTC+10, tampe125 wrote:

Welcome to the club!
Did you ever tried to create a component compatible with J1.5 and J2.5?
You'll see tons of these examples: quoteName became nameQuote, authorise became authorize and so on...

Right, but the naming convention was done in a backward compatible way.  Notwithstanding the occasional mistake, the Platform is not in the habit of just deleting API without taking them through a lengthy deprecation period, usually in the vicinity of a year (sometimes a bit more, sometimes less in special circumstances).

Now, "authorise" is a little different because the action names also changed between 1.5 and 1.6 (which really should be considered 2.0).  This was a direct result, for better or worse, of the massive upgrade to the access control system.

Regards,

Andrew Eddie