Welcome Guest, Not a member yet? Register   Sign In
Helpers and Other Conventions
#21

Let's step back and look at pros and cons, because I'm worried this is becoming a case of "the language offers it so we must use it". To me there is only one pro: it makes it easy to override the function. But there are more cons, including more teaching designers to how to use the "use" statement, more complex code to make custom functions work in libraries like form validation, and in general, more typing, which has been complained about in other threads.

What does everyone think are the pros and cons here? And are the pros enough to outweigh the cons?
Reply
#22

(This post was last modified: 06-30-2016, 07:30 AM by prezire.)

(06-30-2016, 06:14 AM)kilishan Wrote: Let's step back and look at pros and cons, because I'm worried this is becoming a case of "the language offers it so we must use it". To me there is only one pro: it makes it easy to override the function. But there are more cons, including more teaching designers to how to use the "use" statement, more complex code to make custom functions work in libraries like form validation, and in general, more typing, which has been complained about in other threads.

What does everyone think are the pros and cons here? And are the pros enough to outweigh the cons?

Now that you put that way, yes, there are more cons indeed. Good one on the language offer.
Long live CodeIgniter!
Reply
#23

(06-30-2016, 06:14 AM)kilishan Wrote: To me there is only one pro: it makes it easy to override the function.

This "pro" doesn't exist.

Quite the opposite - one of the main reasons why static metods are discouraged today is that you can't extend/override/whatever them, which prevents mocking for unit testing purposes.

Of course, "helper functions" are supposed to be stateless and as such you shouldn't need to mock them, so that's not our problem. I'm just giving an example with that.
Reply
#24

Let us look at the topic through Twig syntax:

Code:
<a href="{{ site_url() }}">Home</a>

Clean and understandable. I think that the current CI3 helpers are fine.
Reply
#25

(This post was last modified: 06-30-2016, 11:03 AM by ivantcholakov. Edit Reason: 4. )

There are three decisions to be made:

1. Should the helpers stay as they are or should they be renamed.
2. Should the helpers be put under namespaces.
3. What would be the elegant way of loading the helpers.

If these decisions are considered separately it would be easier.

Edit:
4. Static classes implementation - I agree with Narf.

Edit 2:
The status of this RFC https://wiki.php.net/rfc/function_autoloading as far as I can see is "Re-proposed" at the moment, v0.3, targeted at PHP 7.1.x
I don't see votes below yet.
Reply
#26

@ivantcholakov:

Actually...
1) the helpers cannot stay as they are; a bunch of them won't be needed, and they may refer to CI3 "stuff"
2) exploiting namespaces is part of the reason for the rewrite, so yes
3) this is worthy of discussion, and I thought that is what this thread was about
4) agreed - static classes are not appropriate

Only #3 needs a decision

One of my earlier posts in this thread suggested a way to go forward elegantly for that.
Reply
#27

About the PHP function autoloading feature I asked the author what is the status of his RFC https://plus.google.com/1111696421301874...5kaDJjkTU3

If this feature gets implemented in PHP 7.1 that would be a significant improvement IMO. I hope for getting a response.
Reply
#28

(06-30-2016, 11:47 AM)ivantcholakov Wrote: About the PHP function autoloading feature I asked the author what is the status of his RFC https://plus.google.com/1111696421301874...5kaDJjkTU3

If this feature gets implemented in PHP 7.1 that would be a significant improvement IMO. I hope for getting a response.

That looks interesting, and consistent with our current autoloader.
It will be good to find out where it sits.
Reply
#29

(06-30-2016, 12:53 AM)jlp Wrote: Without getting hungup on specific names, etc, it sounds like something along the lines of the following might be a good approach. Thoughts?

CodeIgniter4?? ...

system/helpers/URL.php
Code:
namespace CodeIgniter\Helpers\URL;

    function siteURL($uri = '', $protocol = NULL)
    {
        return ...
    }
...

application/whatever...
Code:
use CodeIgniter\Helpers\URL;
...
echo URL\siteURL();

I borrow...

Code:
use CodeIgniter\Helpers\URL;

function site_url()
{
   return URL\SiteURL();
}

echo site_url();


and done... Smile
Reply
#30

(This post was last modified: 06-30-2016, 03:59 PM by prezire.)

Namespace does indeed mess up the traditional helper's simple structure especially with reserved keywords. There may be workarounds but I doubt its practicality especially during future revisions. Due to the reserved keywords exception, my procedural approach ended up with something like below which isn't a good idea:

PHP Code:
use function Helpers\ArrayHelper\elements;
use function 
Helpers\ArrayHelper\read as arrayRead;
use function 
Helpers\FileHelper\read as fileRead;
elements();
arrayRead();
fileRead(); 

Beginners are going to scream seeing that structure especially by the time they create their own helpers.
Long live CodeIgniter!
Reply




Theme © iAndrew 2016 - Forum software by © MyBB