Return to Answer

Fix grammatical and spelling errors

Source Link

edit approved Apr 21, 2015 at 9:43

2.2k
10
22
24

Surely this approach has some benefits, but has also some issues.

It's not really easeeasy to use

If the target of your plugin are WordPress developers, they will be very familiar with plugin API, but end users are not.

For a non-developer, something like:

$data = give_me_the_data();

It's easier to understand, remember and type than:

$data = apply_filters( 'give_me_the_data' );

If you look asat some of the questions on this site, you can understand how much confusion there is regarding action and filters in WordPress among newbie and non developers.

The "typo" issue

As a person that doesmakes a lot of typotypos, I know that they are frustrating. If you write a function with a typo, it throws an error and the user immediately recognizerecognizes the problem, a. A typo in an action name will make the API failsfail but it's pretty harderhard to recognize.

As example:

$data = apply_filters('mp:get-user-data'); // workworks

$data = apply_filters('mo:get-user-data'); // does not work, hard to find why

$data = mp_get_user_data(); // workworks

$data = mo_get_user_data(); // does not work and throws an error, immediately found

The global hell

Actions and filters are just global variables. If you use them to build your API, your code can be f***ed up by any single other line of code present in the system.

It means that a bug in any who-knowknows-which plugin can make your plugin fails withoutfail for no apparent reason. And the resaonreason is that is not your plugin to fail.

Example:

do_action( 'mp:send-notification', $user_id, $message );

// somewhere else
add_action( 'all', 'do_something_bad_that_makes_your_plugin_fail');

Moreover, anyone can use those hooks and even if it may bring a lot of flexibility to your API, it also introduces a lot of complexity.

For example, if you use objects as arguments, being objects passed by reference, it's possible they are modified before your callback runs.

Conclusion

These are all the reasons that come now into my mind. But, but maybe there are other reasons if this approach is not widely used.

For me, I would not use this approach, especially for the last point, but I can not say it is absolutely wrong in WordPress context.

So I don't want to strongly discourage you in using it, just suggesting to consider all the issues in advance, because once you publicly release an API than, it's very hard to switch.

Surely this approach has some benefits, but has also some issues.

It's not really ease to use

If the target of your plugin are WordPress developers, they will be very familiar with plugin API, but end users are not.

For a non-developer something like:

$data = give_me_the_data();

It's easier to understand, remember and type than

$data = apply_filters( 'give_me_the_data' );

If you look as some of the questions on this site, you can understand how much confusion there is regarding action and filters in WordPress among newbie and non developers.

The "typo" issue

As a person that does a lot of typo, I know that they are frustrating. If you write a function with a typo it throws an error and the user immediately recognize the problem, a typo in action name will make the API fails but it's pretty harder to recognize.

As example:

$data = apply_filters('mp:get-user-data'); // work

$data = apply_filters('mo:get-user-data'); // does not work, hard to find why

$data = mp_get_user_data(); // work

$data = mo_get_user_data(); // does not work and throws an error, immediately found

The global hell

Actions and filters are just global variables. If you use them to build your API, your code can be f***ed up by any single other line of code present in the system.

It means that a bug in any who-know-which plugin can make your plugin fails without no apparent reason. And the resaon is that is not your plugin to fail.

Example:

do_action( 'mp:send-notification', $user_id, $message );

// somewhere else
add_action( 'all', 'do_something_bad_that_makes_your_plugin_fail');

Moreover, anyone can use those hooks and even if it may bring a lot of flexibility to your API, it also introduces a lot of complexity.

For example, if you use objects as arguments, being objects passed by reference, it's possible they are modified before your callback runs.

Conclusion

These are all the reasons that come now into my mind. But maybe there are other reasons if this approach is not widely used

For me, I would not use this approach, especially for the last point, but I can not say it is absolutely wrong in WordPress context.

So I don't want to strongly discourage you in using it, just suggesting to consider all the issues in advance, because once you publicly release an API than it's very hard to switch.

Surely this approach has some benefits, but has also some issues.

It's not really easy to use

If the target of your plugin are WordPress developers, they will be very familiar with plugin API, but end users are not.

For a non-developer, something like:

$data = give_me_the_data();

It's easier to understand, remember and type than:

$data = apply_filters( 'give_me_the_data' );

If you look at some of the questions on this site, you can understand how much confusion there is regarding action and filters in WordPress among newbie and non developers.

The "typo" issue

As a person that makes a lot of typos, I know that they are frustrating. If you write a function with a typo, it throws an error and the user immediately recognizes the problem. A typo in an action name will make the API fail but it's pretty hard to recognize.

As example:

$data = apply_filters('mp:get-user-data'); // works

$data = apply_filters('mo:get-user-data'); // does not work, hard to find why

$data = mp_get_user_data(); // works

$data = mo_get_user_data(); // does not work and throws an error, immediately found

The global hell

Actions and filters are just global variables. If you use them to build your API, your code can be f***ed up by any single other line of code present in the system.

It means that a bug in any who-knows-which plugin can make your plugin fail for no apparent reason. And the reason is that is not your plugin to fail.

Example:

do_action( 'mp:send-notification', $user_id, $message );

// somewhere else
add_action( 'all', 'do_something_bad_that_makes_your_plugin_fail');

Moreover, anyone can use those hooks and even if it may bring a lot of flexibility to your API, it also introduces a lot of complexity.

For example, if you use objects as arguments, being objects passed by reference, it's possible they are modified before your callback runs.

Conclusion

These are all the reasons that come now into my mind, but maybe there are other reasons if this approach is not widely used.

For me, I would not use this approach, especially for the last point, but I can not say it is absolutely wrong in WordPress context.

So I don't want to strongly discourage you in using it, just suggesting to consider all the issues in advance, because once you publicly release an API, it's very hard to switch.

Source Link

created Apr 19, 2015 at 12:33

gmazzap

46.3k
6
95
147

Surely this approach has some benefits, but has also some issues.

It's not really ease to use

If the target of your plugin are WordPress developers, they will be very familiar with plugin API, but end users are not.

For a non-developer something like:

$data = give_me_the_data();

It's easier to understand, remember and type than

$data = apply_filters( 'give_me_the_data' );

If you look as some of the questions on this site, you can understand how much confusion there is regarding action and filters in WordPress among newbie and non developers.

The "typo" issue

As example:

$data = apply_filters('mp:get-user-data'); // work

$data = apply_filters('mo:get-user-data'); // does not work, hard to find why

$data = mp_get_user_data(); // work

$data = mo_get_user_data(); // does not work and throws an error, immediately found

The global hell

Actions and filters are just global variables. If you use them to build your API, your code can be f***ed up by any single other line of code present in the system.

It means that a bug in any who-know-which plugin can make your plugin fails without no apparent reason. And the resaon is that is not your plugin to fail.

Example:

do_action( 'mp:send-notification', $user_id, $message );

// somewhere else
add_action( 'all', 'do_something_bad_that_makes_your_plugin_fail');

Moreover, anyone can use those hooks and even if it may bring a lot of flexibility to your API, it also introduces a lot of complexity.

For example, if you use objects as arguments, being objects passed by reference, it's possible they are modified before your callback runs.

Conclusion

These are all the reasons that come now into my mind. But maybe there are other reasons if this approach is not widely used

For me, I would not use this approach, especially for the last point, but I can not say it is absolutely wrong in WordPress context.

So I don't want to strongly discourage you in using it, just suggesting to consider all the issues in advance, because once you publicly release an API than it's very hard to switch.