Constants defined in kohana/index.php (application) about core HOT 18 CLOSED

1. I agree these should be injected into the Filesystem object (if we ever get to having one)
2. Neither is going to be used for 'security' anymore

from core.

@kemo

1. Filesystem or Kohana_Core (easy way) or Autoload (classes) object + contained EXT (best way).
2. Planned to complete remove 'security'?

from core.

1. There is a feature branch @zombor has started regarding a Filesystem class.
2. Direct access check for security was proposed & accepted in #508 and was implemented in #529.

from core.

@enov

1. are you seriously? ugly solution - just few first strings:

protected $_include_paths = array();

public function __construct(array $paths)
{
    $this->_paths = $paths;
}

Class must be static (to be available everywhere) and may include the methods for autoloading classes, constant with file extension.

2. great! have not seen it before (( @lenton 👍

from core.

We're trying to move away from static classes. What you see there is just a mock @zombor did, it's not the final solution. Having it as an object provides infinite benefits over having it static and IMHO should stay that way.

Passing / injecting the Filesystem object should be something the developer takes care of.

from core.

@kemo 👍

@WinterSilence you should follow the fashion 💅 ... static is a bad word nowadays 😄

from core.

a huge milestone...

from core.

@kemo

We're trying to move away static classes.

What are the advantages of such an option?

For example, I want to display in the template(view) list of paths, how to get this object?

from core.

@cyrgit

Most of the time, if you're using static methods or variables then there is almost certainly a better way.
That said, there are a few instances where static methods and variables are useful.
However, all of these are accessed solely by methods in the class that also contains the statics, and do not have dependencies on anything outside them.

from core.

@cyrgit You're right, I made a mistake in translation. But then I do not understand how you plan to dynamically use the helpers (Arr, HTML, etc) - I do not see in the project implementation of pattern "service locator" or something similar.

For example, I want to display in the template(view) list of paths, how to get this object? Describe at least schematically.

from core.

@WinterSilence think of it as static == global == procedural == something is wrong

If there is no way to get the object to another object that needs it, something else is wrong - in that case you'd probably be doing it via a DI container / service manager.

Filesystem (object) -> App\Kohana\Whatever (object) -> wherever else you need it. And you'll be able to have multiple "filesystems", it doesn't have to always be the "main one" current app is relying on

from core.

And yes, those 'helpers' are in essence procedural function containers (which is ok as long as they have no external dependencies - which they usually don't).

from core.

@kemo

If there is no way to get the object to another object that needs it, something else is wrong - in that case you'd probably be doing it via a DI container / service manager.

Then at the beginning to create an environment in which your solution can work, and after that start to create them. If the new environment is absent, then need use the old environment and delay global changes until the next release.

And yes, those 'helpers' are in essence procedural function containers (which is ok as long as they have no external dependencies - which they usually don't).

Filesystem have external dependencies?

from core.

@cyrgit I've said that your code is not perfect - read the title

https://github.com/cyrgit/kli/blob/d9bc71ca95ecc70e3587497e24c2065366b264c8/classes/Kohana/CLI/Command.php#L79

from core.

@cyrgit Why you think that I don't know DI?)) I'm trying to say: each project has its own "face" (style).
Abstraction is nice, but there is Zend and as a result of these changes get his clone. I think that this project should strive for an optimal solution, not the ideal solution.

from core.

@cyrgit

It appeared that way from your comments insisting on a static Filesystem class

If your opponent has a different point of view, it does not mean that he is not familiar with your.

questioning how could a view ever be built without a static factory.

Answer this question, by the way, I did not see. I did not say anything about the factory.
By the way the factory should be a separate class, not static crutch as in your.

P.s. Builder must use the "lazy" loading and cascade system, once you make a module for Kohana.

from core.

@cyrgit

This in reference to your request on how a view object should be created, which is currently done by a static factory in the code. It's a bit hard to understand your English sometimes so perhaps that is not what you were asking?

Write abstract http application that execute a Request, launched Controller, returned View displayed paths of Filesystem.

What I'm building deprecates the use of modules all together and relies on Composer, so there is no need for that with proper namespaces and PSR4 autoloading.

Also cascading filesystem used in config.

from core.

Closing this since point 1 already exists as an issue and point 2 has already been addressed by removal.

from core.