Helpers and Other Conventions

Another way to solve reserved keywords might be through pluralization. Since directories are containers, they can be made plural. And since namespaces represent a structure of directories (although not most of the time), they can made plural:

PHP Code:

//Helpers/Array.php. Yes, the filename is singular.
namespace Helpers\Arrays; //Plural namespace.
function elements()
{
  return [];
} 


PHP Code:

//SomeFile.php
Helpers\Arrays\elements();
Helpers\Files\read(); 


Long live CodeIgniter!

Another way to solve reserved keywords might be through pluralization. Since directories are containers, they can be made plural. And since namespaces represent a structure of directories (although not most of the time), they can made plural:

PHP Code:

//Helpers/Array.php. Yes, the filename is singular.
namespace Helpers\Arrays; //Plural namespace.
function elements()
{
  return [];
} 


PHP Code:

//SomeFile.php
Helpers\Arrays\elements();
Helpers\Files\read(); 


Again, the array helper is useless.
It shouldn't exist.

Don't obseess over that one keyword.

Another way to solve reserved keywords might be through pluralization. Since directories are containers, they can be made plural. And since namespaces represent a structure of directories (although not most of the time), they can made plural:

PHP Code:

//Helpers/Array.php. Yes, the filename is singular.
namespace Helpers\Arrays; //Plural namespace.
function elements()
{
  return [];
} 


PHP Code:

//SomeFile.php
Helpers\Arrays\elements();
Helpers\Files\read(); 


Again, the array helper is useless.
It shouldn't exist.

Don't obseess over that one keyword.

The goal is how to make CI4 awesome and solve issues like reserved keywords in namespaces and not to specifically fantasize for the Array helper to get shoved into the framework. Since there aren't any clear and final list of helpers for CI4, I used Array as an example because it's one of CI's native common helpers. Remove it if necessary.

Long live CodeIgniter!

The goal is how to make CI4 awesome and solve issues like reserved keywords in namespaces and not to specifically fantasize for the Array helper to fit into the framework. Since there aren't any clear and final list of helpers for CI4, I used Array as an example because it's one of CI's native common helpers. Remove it if necessary.

To make it awesome, it needs to solve problems that exist. It's not like there are a thousand keywords that you need to avoid - array is literally the only one.

In case of Anthony Ferrara's RFC about function autoloading gets rejected (I would sorry if it happens again), there is an approach that I saw in stackoverflow and other places, it is a PHP-based implementation. Here is a link to an article where the approach seems to be best explained, there is room for optimizations, of course:

https://bryanjhvtk.wordpress.com/2014/03...ading-php/

This seems to me a possible backup alternative.

The goal is how to make CI4 awesome and solve issues like reserved keywords in namespaces and not to specifically fantasize for the Array helper to fit into the framework. Since there aren't any clear and final list of helpers for CI4, I used Array as an example because it's one of CI's native common helpers. Remove it if necessary.

To make it awesome, it needs to solve problems that exist. It's not like there are a thousand keywords that you need to avoid - array is literally the only one.

That's the reason I had File as a secondary example. I must have missed it, but for the sake of this thread, please provide a link that explicitely says CI4 should not include the Array helper implementation.

Long live CodeIgniter!

1 Proposal from me.. 

Lets define Helper Interface or abstract Helper and all Helpers to become Classes. 
I will use the url_helper to explain my simple idea.

1. Why to set class instead of the current functions ?
   In most of the cases inside any helper all functions have common resources which they use.In our case we can see that most of the helper functions are using Config\App, \CodeIgniter\HTTP\URI and \CodeIgniter\Services. If its 1 class with a couple of methods the how PHP OOP idea which CI is following at first place will be kept.
   
2. What will help that ?
   With class it will be a lot easier to extend any of those helper methods. Directly CI\Helper\URI can be extended inside a App\Helper\URI accessing all the services which are prepared for the URI with really easy option to control those default methods which are used at many places at any app.
   
3. Accessing in all app layers Helpers..
   Helpers must be available at any place in the Apps so I think that both ways with new instance or static instance should be possible. The plus is that by this way some unnecessary code can be skipped. I mention that specially for Views as in all other places I don't see a reason to do that.. 
   URI::base_url() is a little bit shorter then something as URI::instance()->base_url().
   

Any group of helpers usually has common services/resources or logic and that is the reason why they are grouped.
I believe that such groups should be merged into one Class which will share any common features fast and easy.

Such complains as too long namespaces are not realistic at least for me.. because those days Composer is used massive and there some libraries which are used have really long classname + namespace .. 
Its absurd somebody to complain that he have to define what is he using at his own app..

Regards

Best VPS Hosting : Digital Ocean

1 Proposal from me.. 

Lets define Helper Interface or abstract Helper and all Helpers to become Classes. 
I will use the url_helper to explain my simple idea.

1. Why to set class instead of the current functions ? 
   

• In most of the cases inside any helper all functions have common resources which they use.
  

1. In our case we can see that most of the helper functions are using Config\App, \CodeIgniter\HTTP\URI and \CodeIgniter\Services. If its 1 class with a couple of methods the how PHP OOP idea which CI is following at first place will be kept. 

... that's not a helper.

In case of Anthony Ferrara's RFC about function autoloading gets rejected (I would sorry if it happens again), there is an approach that I saw in stackoverflow and other places, it is a PHP-based implementation. Here is a link to an article where the approach seems to be best explained, there is room for optimizations, of course:

https://bryanjhvtk.wordpress.com/2014/03...ading-php/

This seems to me a possible backup alternative.

There are easier hacks, you just have to trigger the class auto-loader.

The goal is how to make CI4 awesome and solve issues like reserved keywords in namespaces and not to specifically fantasize for the Array helper to fit into the framework. Since there aren't any clear and final list of helpers for CI4, I used Array as an example because it's one of CI's native common helpers. Remove it if necessary.

To make it awesome, it needs to solve problems that exist. It's not like there are a thousand keywords that you need to avoid - array is literally the only one.

That's the reason I had File as a secondary example. I must have missed it, but for the sake of this thread, please provide a link that explicitely says CI4 should not include the Array helper implementation.

"File" is not a keyword.

I've explicitly said it already, and I'll say it again: CI4 should not include an "array helper".

My posts are your links.

1 Proposal from me.. 

Lets define Helper Interface or abstract Helper and all Helpers to become Classes. 
I will use the url_helper to explain my simple idea.

1. Why to set class instead of the current functions ?
   In most of the cases inside any helper all functions have common resources which they use.In our case we can see that most of the helper functions are using Config\App, \CodeIgniter\HTTP\URI and \CodeIgniter\Services. If its 1 class with a couple of methods the how PHP OOP idea which CI is following at first place will be kept.
   
2. What will help that ?
   With class it will be a lot easier to extend any of those helper methods. Directly CI\Helper\URI can be extended inside a App\Helper\URI accessing all the services which are prepared for the URI with really easy option to control those default methods which are used at many places at any app.
   
3. Accessing in all app layers Helpers..
   Helpers must be available at any place in the Apps so I think that both ways with new instance or static instance should be possible. The plus is that by this way some unnecessary code can be skipped. I mention that specially for Views as in all other places I don't see a reason to do that.. 
   URI::base_url() is a little bit shorter then something as URI::instance()->base_url().
   

Any group of helpers usually has common services/resources or logic and that is the reason why they are grouped.
I believe that such groups should be merged into one Class which will share any common features fast and easy.

Such complains as too long namespaces are not realistic at least for me.. because those days Composer is used massive and there some libraries which are used have really long classname + namespace .. 
Its absurd somebody to complain that he have to define what is he using at his own app..

Regards

Libraries != helpers.
Static classes != OOP.
Static functions are NOT extendable or overridable.

Helpers are only useful for their short names. You'd use a full-featured library if you didn't mind writing more code, and there's nothing wrong with that, just don't call that "helpers".

Forget my previous examples. The goal is to use namespaces on procedural files. Let's say for the sake of argument, I create a school app that has Student and Class objects in it. I then decide to create a Class helper. How should I structure my namespace?

Reserved words in namespaces can be done with a couple of tweaks but that would be a complete hack.

If this thread goes any further, it would be best to just make helpers similar to CI3 but this time using camelCase (I hope) :-D

Long live CodeIgniter!

Forget my previous examples. The goal is to use namespaces on procedural files. Let's say for the sake of argument, I create a school app that has Student and Class objects in it. I then decide to create a Class helper. How should I structure my namespace?

Reserved words in namespaces can be done with a couple of tweaks but that would be a complete hack.

This is not CodeIgniter's problem.