[wp-hackers] wp releases : is it planned in any way ?

[Jacob Santos]

Ah, I like to think of the WordPress API as a black box in which my 
solutions do not involve modifying the core purpose of WordPress 
functions to serve my ends. In programming, you are not always going to 
have the advantage of being able to modify the library for which you 
use, therefore it makes for almost disappointing practice to assume that 
the author of the library you use will bow to your will, just because it 
will make your life easier.

After looking it over again, it would be super easy to include the 
taxonomy argument with little overhead and increase the power of a few 
relatively general purpose functions. I can then agree that I should 
withhold further judgment until I see a patch for which to critique. It 
is not the way I would have went about solving the problem if it was me, 
but I forget not everyone is a fan of torturing themselves.

Malaiac wrote:
> 2008/9/12, Jacob Santos <wordpress at santosj.name>:
>   
>> Of the 9 line function body, you only need 2 lines to create
>> your own function. I'm not sure where you are getting 2000 lines of code,
>> but forcing the core code to dance around your modifications is not
>> something I would be happy about without good enough reason.
>>     
> I don't need the modification to actually get the categories of my own
> taxonomy. I need the modification for all the other WP functions to
> get the categories of my own taxonomy.
>
> Without the mod, I'd have to recode one or two dozens of (big)
> functions which start by $categories = &get_categories($r); and do not
> apply filters on it. Maybe not 2 000 lines of code, but surely like a
> 40ko futile copy / paste of functions, and conditional tags in all the
> templates files ( if(is_directory()) my_list_categories($args); else
> wp_list_categories($args); ).
> Copy pasting is not above my level, and time is not an issue (find and
> replace 'category' => 'my_category' ). But adding 40k of code, and
> almost making a fork of major WP functions is an issue regarding speed
> and future maintenance.
>   

is_directory() actually does sound pretty good function. I would add a 
prefix to any function you create that is uniform for your plugin, 
myplugin_is_directory() and myplugin_my_list_categories().

>>  Functions of that limited purpose
>>     
> woosh. did you count the occurences of get_categories() calls (front
> and back ends)  ?
>   

I should have said, "specific purpose", which is to get the category 
taxonomy of /WordPress/, not every taxonomy in WordPress and plugins. If 
it won't be that much more to add the taxonomy to the argument and allow 
it to be used, it makes sense to want to allow those to be reused. Reuse 
is a programming concept I agree with.

>> get_terms() is well flexible enough to allow you enough freedom to
>> employ in any fashion to create your own function for what you have in mind.
>>     
> Well, I'd like all these major WP functions to know what I have in my
> mind, but well..

That doesn't sound like good development practices. There are many 
libraries that I wish would do thing differently, but hey, they aren't 
going to change just because of one punk guy saying, "You should allow 
unlimited or additional extensibility." It would make more sense to 
create a generic function which do the dropdown, because I believe there 
are several areas that offer that functionality.

So instead of widening the scope of specific functions for yet another 
purpose, you are bloating those functions. Then again, for performance 
reasons, in tests I've done creating another function to reduce 
redundancy ends up increasing overhead from PHP having to create the 
function stack, setup the variables and then exit the stack when complete.

I will say that the Plugin API has an upper limit of how many hooks that 
can be performed before it takes a full second to perform those actions. 
Depends on your system, but I do like my system because everything is 
slower and I can actually see how long functions take relative to each 
other. You might want to test the performance of your plugin, depending 
on the size of it.

Well, for performance reasons, you can still create the generic dropdown 
based on the code from categories, users, etc, but not use it in the 
WordPress API. Have it just for plugins.

>>  You can also create an wrapper around get_categories by using the 'include'
>> argument for get_categories(). If you get the IDs of the terms of your
>> taxonomy, you can include your specialized categories along with the
>> WordPress ones.
>>     
> my specialised categories don't mix with post categories. and fetching
> the correct ID for all categories call = twice the SQL load.
>   

Indeed. I remembered too late that the WHERE clause might also include 
the taxonomy.

>   
>>  You can also hook into the 'get_terms' filter and look for the 'category'
>> and 'link_category' taxonomies to add your taxonomy terms to.
>>     
> the get_terms filter is way too late in the function to do that. I
> mean, it is in the right position (just before the return), but it's
> after the query and after the sorting.
>
>   

It would be at a cost to have to go through all of the get_terms 
functionality just to replace it with your own. It would be easier and 
at a lower cost to simply pass the correct taxonomy to begin with.

>   
>>  I mean, I not
>> sure exactly what you are trying to achieve or how, but there are several
>> ways around not doing anything to get_categories().
>>     
>
> Well, after DD32 thoughtful reply, a simple filter addition would do
> the trick, without compromizing the code.
>
>   

Yeah, if your purpose is to make the other functions that use 
get_categories more general purpose, then it seems that the action you 
are preforming is one that is known before hand and can be passed as one 
of the arguments. No filter, just allow the taxonomy to be set within 
the $args parameter.

> Well I guess you have your answer now, don't you ?
>   
No, my limiting factor is that I'm a zealot for my programming paradigm. 
I don't agree with what you are trying to achieve based on one of my 
principles for programming. I don't do things, because I'm limited by my 
average IQ, well not always at least. I do it because I feel it is the 
right way to do it.

It would be nice if WordPress was more flexible, but it would be at the 
cost of time and performance. My fear is still that another is going to 
come along and soon this and that does this and also that as well as 
another several tasks it was not meant for.

The functions you point to are for presentation and in my programming 
paradigm it is acceptable to recreate new functions for your specific 
purpose or refactor existing presentation functions to allow for 
additional reuse. From what you described, to me the solution is either 
to 1) add filters to those dozen or so functions to allow for reuse (the 
negative impact of performance is justified by only having the filter 
where it is needed or 2) create a generic API for presentation layer and 
allow reuse of it instead.

You will notice that I don't mention get_categories(). There are 
disadvantages to everything. Mostly the time it will take increases with 
those two, your solution would probably take less than 30 minutes to 
complete whereas, the second solution would take several hours, plus 
additional time for testing and writing test cases. Those are my ideal 
solutions, but I doubt I'm going to implement them myself.

So you know, another one of my programming principles is that if you can 
do something in five minutes verses 8 hours, then I'm going to go with 
the five minutes solution first and put the "right" 4 to 8 hour solution 
on the back burner. But you know, it is the weekend coming up, so if you 
insult my intelligence further, I might just jump in to action to prove 
you wrong. Whether or not I succeed is really not the issue at that 
point. Also, probably not going to be committed since it would be an 
overwhelming change and it is a little late in the development cycle. It 
would take more debate than you know an additional three lines of code 
to get_categories().

Jacob Santos