We could create a command to generate a file. Or include the file directly into the Core.

After #96, we must continue to split the core. Goal: Remove Hoa\Core.
We have to split Hoa\Core\Parameter and Hoa\Core\Data, and also Hoa\Core\Core. What is the strategy here? We must (i) find namings and (ii) find if they must exist (if they have a future). What do you think?

In worker shell status, we can specify Run directory by --run option

\Hoa\Core::getInstance()->initialize(array(
   'protocol.Data/Variable/Run' => $run . DS
));
resolve('hoa://Data/Variable/Run/');
>> hoa/flatland

resolve('hoa://Data/Variable/Run/', false, true);
>> /home/user/Project/MyRepo.git/vendor/hoa/core/Hoa/Data//Variable//home/user/Project/MyRepo.git/src/Data/Variable/Run/

\Hoa\Core::getInstance()->getParameters()->getParameter('protocol.Data/Variable/Run');
>>/home/user/Project/MyRepo.git/src/Data/Variable/Run/

assign Hoa://Data/Variable/Run seems doing messy in resolve() result.
unlike of Hoa://Data work well

like Hoa\Worker\Run::find use hoa://Data/Variable/Run/
worker cannot be find in path specify by --run

Let the following program:

<?php

require '/usr/local/lib/Hoa/Core/Core.php';

echo phpversion(), "\n";
print_r(get_defined_functions()['user']);

With 5.4.24, we have:

5.4.24
Array
(
    [0] => �
    …
)

With 5.7.0-dev (or other versions different of 5.4.[some specific versions]):

5.7.0-dev
Array
(
    [0] => ƒ
    …
)

Hello :-),

It appears that the ~0.0 requirement in some composer.json files and in some README.md files can afraid some people. We have two solutions:

1. replace ~0.0 by ~0.1 (which does not change anything for us…) in README.md files (in the “Installation” section),
2. replace ~0.0 by ~0.1 also in composer.json files.

Thoughts? /cc @hoaproject/hoackers

Could save a lot of line and avoid possible bugs :-).

Hi,
I think it can be cool to add some parameter keywords like :ds: and :rs: (see #29 for RS).

The goal is to avoid any long concatenation when setting parameters.

It should friendly create a method to redefine the main roots of the Hoa wrapper.

$hoa = Hoa\Core\Core::getInstance();
$hoa->getParameters()->setParameter('root.application', __DIR__);
$hoa->getParameters()->setParameter('root.data', __DIR__ . DS . 'Data');
$hoa->setProtocol();

What do you think about something like unresolve($data, $application=null, $hoa=null);?

Related to #80.

It could break some codes. This is the last things to do.

hello,
I think we need to say in the readme that this is deprecated and on packagist https://packagist.org/packages/hoa/core too.

what do you think on that?

If the 'hoa' binary strictly depends on Hoa\Console to be installed, I feel it would be better if the binary came with Hoa\Console.

Without Hoa\Console you basically end up with a broken binary in everybody's bin directory. Since Hoa\Console depends on Hoa\Core to work anyway, it would be more logical (in my head at least) that it ships with Hoa\Console.

https://github.com/hoaproject/Core/blob/master/Core.php#L173 is causing language issues over at OC is there a possible workaround for this? we've found that commenting this line out resolves the issue with using non-ASCII Chars

Not sure the impact that could have in other areas though?

Usually, I never write the last directory separator when I set a path.
So this code fails:

from('Devengers')
-> setRoot('/home/agerlier/Documents/Libraries.hoa')
-> import('Hero.Identity~')
-> import('Hero.Kit.Uuid')
;

The correct Hoa syntax is -> setRoot('/home/agerlier/Documents/Libraries.hoa/')
Perhaps, we should add an implicit ending directory separator in the Core?

We should avoid automatic definition of what we estimate as a good thing like this

It should be a command which pilot user to edit its configuration to use good thinkgs (UTC as timezone, etc....)

This command could be part of Hoa\Core ?

Thought ?

How I can fix this??

I'm including hoa/math in my project so that I can evaluate arithmetic expressions (which is great, btw!). Unfortunately, this means Hoa's Core.php automatically initializes, unexpectedly polluting the global namespace and running code that can easily throw errors if run at the wrong time. Examples:

• A couple dozen constants are defined across multiple files in the global namespace. None have even a vendor prefix.
• Global configuration is changed without warning (i.e, mb_internal_encoding()).
• Global functions _define() and event() are defined, meaning I can't define them for my own project. I only realized this when I tried calling Laravel's event() function.
• date is called, so if your php.ini doesn't have a timezone set, you get an error.

Because of your composer.json, all of this happens before any of my project's code has a chance to run, so the fact that Laravel defines an event() function doesn't matter, nor does its setting the timezone prevent Hoa from throwing an error.

Could you put your constants in a class and your functions in Hoa's namespace? Then you could also do the initialization in the constructor and remove Core.php from the autoload "files" array. 99% of request to my app don't require Hoa, so I don't expect it to initialize until its needed.

I use PhpMetrics within a project and PhpMetrics has a dependency on hoa/core.

Today I added the HTMLPurifier to the project (using composer) and the following error appears:

RuntimeException: The autoloader expected class "HTMLPurifier\Bootstrap" to be defined in
file "/path/vendor/ezyang/htmlpurifier/library/HTMLPurifier/Bootstrap.php". The file
was found but the class was not in it, the class name or namespace probably has a typo.

The Stacktrace:

in /path/vendor/symfony/symfony/src/Symfony/Component/Debug/DebugClassLoader.php line 189
at DebugClassLoader->loadClass('HTMLPurifier\Bootstrap')
at spl_autoload_call('HTMLPurifier\Bootstrap') in /path/vendor/hoa/core/Hoa/Core/Consistency.php line 288
at Consistency->_import('HTMLPurifier.Bootstrap', true) in /path/vendor/hoa/core/Hoa/Core/Consistency.php line 335
at Consistency::autoload('HTMLPurifier_Bootstrap')
at spl_autoload_call('HTMLPurifier_Bootstrap') in /path/vendor/exercise/htmlpurifier-bundle/Exercise/HTMLPurifierBundle/ExerciseHTMLPurifierBundle.php line 11
at ExerciseHTMLPurifierBundle->boot() in /path/app/bootstrap.php.cache line 2305
at Kernel->boot() in /path/app/bootstrap.php.cache line 2333
at Kernel->handle(object(Request)) in /path/web/app_dev.php line 27

As you can see the Autoloading is broken because it now looks for HTMLPurifier\Bootstrap instead of HTMLPurifier_Bootstrap.

hi,

Point 1: At this moment, all libraries has dependency on hoaproject/core, itself has a exception handler which can have some conflicts with other exception handlers (symfony|(other fwk, i never tested) ...

Imagine user install any hoa library on his fwk, he may not want to install a new exception handler ...

Point 2: If you're agree with that, should it be activated by default ? Should this exception handler be enabled on a full stack version of hoa ? (sohoa)

Thought ?

In our scenario, we have a project that depends on Hoa\Bench.

We also have globally installed packages (composer global), in particular phpunit and other Hoa dependencies.

The phpunit binary is executed globally for our package. This means that there are two composer autoloaders active, each load a copy of Hoa\Core, even though the global one does not require it.

This causes this error:

phpunit --configuration tests/phpunit.xml
Hoa main file (Core.php) must be included once.

The root cause for this, is that Core.php is loaded regardless of it it's ever used or not.

Source: https://github.com/fruux/sabre-vobject/issues/238

It would be nice if there is a solution to this =) Hope all is well!

hi,

Point 1: At this moment, all libraries has dependency on hoaproject/core, itself has a autoloading system and users may not want to have a Xth autoloading system activated.

Point 2: If you're agree with that, should it be activated by default ? Should this autoloading system be enabled on a full stack version of hoa ? (sohoa)

Thought ?

Several questions:

1. does it impact performance?
2. how does it impact performance?

Depending on these answers:

1. should we introduce a workaround in Hoa\Core\Consistency?
2. should we patch php-src and HHVM?

Original discussion: hoaproject/Database#19.

Since we require in PHP5.4, this is no longer necessary.

This new condition here makes hoa re-import classes using the ~ pattern, effectively breaking autoloading for other PHP projects (like symfony1).

I'm not entirely sure what it is doing, but commenting this out restores the original behaviour. Could you please take a look at it?

Like brew home.

Will help sabre-io/katana#277 (comment).

Hey :-),

PHP7 introduces some BC breaks and we have to track and fix them before end of June.
Here is the official list that changed: https://github.com/php/php-src/blob/master/UPGRADING.

How to track them?

1. run hoa test:run --all often,
2. run

find . -name "Bool\.php" -o \
    -name "Int\.php" -o \
    -name "Float\.php" -o \
    -name "String\.php" -o \
    -name "Null\.php" -o \
    -name "False\.php" -o \
    -name "True\.php" -o \
    -name "Resource\.php" -o \
    -name "Object\.php" -o \
    -name "Mixed\.php" -o \
    -name "Numeric\.php"

until it results nothing,

1. track some place where BaseException must be used instead of Exception,
2. add retro-compatibility with prior versions of PHP7.

Please, see the discussion here hoaproject/Http#4.

Please, see point 5 of http://php.net/reference.pcre.pattern.differences. Consequently, we are not able to write something like: s/-(.)/\u\1/ to transform foo-bar into fooBar. We have to implement it by ourselves.

• \U,
• \u,
• \L,
• \l,
• \E,
• \e.

Two locations: either in the zFormat or in Hoa\Regex (we would create a new “preg_replace”-like implementation). I would go for Hoa\Regex but it will create a dependency between Hoa\Core and Hoa\Regex which must not happen (in this way). However, supporting it in all regular expressions used in Hoa would be great… So I propose to (1) implement it in the zFormat, and then (2) in Hoa\Regex.

Thoughts?

Needed to continue #56 (comment).

CallbackFilterIterator exists since PHP5.4 (https://github.com/hoaproject/Core/blob/master/Consistency.php#L229).

Related to #80.

Quoting https://github.com/php/php-src/blob/7dcfdbbee431c93c52605e1df323d18e0c6088e9/UPGRADING#L323-L351:

Changes to error handling

• The new base class of the exception hierarchy is BaseException, from which
  Exception extends. Typehints in exception handling code may need to be changed
  to account for this.

• Some fatal errors and recoverable fatal errors now throw an EngineException
  instead. As EngineException extends BaseException but not Exception, these
  exceptions will not caught by existing try/catch blocks.

  For the recoverable fatal errors which have been converted into an exception,
  it is no longer possible to silently ignore the error from an error handler.
  In particular, it is no longer possible to ignore typehint failures.

• Parser errors now generate a ParseException (extends BaseException). Error
  handling for eval()s on potentially invalid code should be changed to catch
  ParseException in addition to the previous return value / error_get_last()
  based handling.

• Constructors of internal classes will now always throw an exception on
  failure. Previously some constructors returned NULL or an unusable object.

• The error level of some E_STRICT notices has been changed.

Relevant RFCs:

• https://wiki.php.net/rfc/engine_exceptions_for_php7
• https://wiki.php.net/rfc/internal_constructor_behaviour
• https://wiki.php.net/rfc/reclassify_e_strict

As I didn't found Embryo.git, I start a Hoa project from scratch. I didn't use the "whereishoa" command.

My first lines are:

<?php

define('DS', DIRECTORY_SEPARATOR);
define('ROOT', dirname(__DIR__));

require ROOT.DS.'Hoa.central'.DS.'Hoa'.DS.'Core'.DS.'Core.php';


from('Hoa')
-> import('File.Write')
;

from('Hoathis')
-> import('Hero.Identity~')
-> import('Hero.Unit.Uuid')
;


event('hoa://Event/Exception')->attach(new Hoa\File\Write('hoa://Data/Variable/Exception.log'));

Then I throw an exception:

throw new \Hoa\Core\Exception('undefined "%s"', crc32(__METHOD__), [$name]);

But if I change 'hoa://Data/Variable/Exception.log' to 'Exception.log', it works.
Where I have to map 'hoa://Data/Variable' to a real path?
Perhaps; you should add a thrown exception if an unregistered stream is used?

I have to write:

$hoa = Hoa\Core\Core::getInstance();
$hoa->setProtocol('hoa://Application/Public', ROOT);
$hoa->setProtocol('hoa://Data', dirname(__ROOT__).DS.'Data');
`̀``
Is it suffisant for all hoa://Data/* paths? 

History

The core gathers several thin layers into a single library for performance reasons. Let me explain it shortly. Parsing time is not very costly compared to I/O: Accessing to a file, opening it and reading it. The core aimed at putting the minimum always needed codes into small files, in order to reduce this I/O time. Since recent PHP versions and recent I/O progresses (SSD, kernel, FS…), this is no longer necessary. We can then split the core.

Global idea

The core contains the following layers:

• Hoa\Core\Consistency,
• Hoa\Core\Data,
• Hoa\Core\Event,
• Hoa\Core\Exception,
• Hoa\Core\Parameter,
• Hoa\Core\Protocol.

We can split it into the following libraries:

• Hoa\Consistency,
• Hoa\Event,
• Hoa\Exception,
• Hoa\Protocol.

They can live outside the core without any problem. So far, though, Hoa\Core\Data and Hoa\Core\Parameter will be kept as is.

Dealing with pre-loading

Hoa\Core\Consistency, Hoa\Core\Parameter and Hoa\Core\Protocol were de-facto pre-loaded with Hoa\Core\Core. This latter is automatically pre-loaded with the autoload.files Composer's property. Whatever the split, we have to ensure this behavior.

Case of Hoa\Core\Consistency

This layer contains:

• An autoloader,
• An xcallable implementation and,
• Consistency helpers/tools accross PHP VMs (backport features to prior VMs, naming consistencies, feature consistencues etc.).

Only the latter is important at any runtime and will be loaded as a separated file with Composer. This will reduce the number of loaded code by approximately 60%.

Case of Hoa\Core\Parameter

Will not be extracted yet. Nothing to do. (see bellow)

Case of Hoa\Core\Protocol

We need to register the hoa:// protocol at any runtime. We use it everywhere. It has never hurt anyone in the whole Hoa's history. So we can load the file that is responsible to register the stream wrapper with Composer. This will reduce the number of loaded code by approximately 50%.

Steps

Here are the following steps to follow (the order is important):

• Hoa\Exception:
  • Create Hoa\Exception (from Hoa\Core\Exception),
  • Write test suites,
  • Update all libraries to use Hoa\Exception,
  • Remove Hoa\Core\Exception.
• Hoa\Event:
  • Create Hoa\Event (from Hoa\Core\Event),
  • Write test suites,
  • Update all libraries to use Hoa\Event,
  • Remove Hoa\Core\Event.
• Hoa\Protocol:
  • Create Hoa\Protocol,
  • Write test suites,
  • Update all libraries to use Hoa\Protocol,
  • Remove Hoa\Core\Protocol.
• Hoa\Consistency:
  • Create Hoa\Consistency,
  • Write test suites,
  • Update all libraries to use Hoa\Consistency,
  • Remove Hoa\Core\Consistency.

Next steps

Continue to split the core, see #97.

Here are the following steps to follow:

• Hoa\Xyl\Data:
  • Move Hoa\Core\Data to Hoa\Xyl\Data,
  • Update Hoa\View and other libraries to understand a mixed data structured instead (to remove a dependency),
  • Remove Hoa\Core\Data.
• Hoa\Parameter:
  • Create Hoa\Parameter (from Hoa\Core\Parameter),
  • Write test suites (optional so far),
  • Remove Hoa\Core\Parameter.
• Remove Hoa\Core:
  • Mark the repository as deprecated,
  • Do we empty the repository?

Update all composer.json files

Because we are dropping PHP5.4 too.

• Acl
• Bench
• Cache
• Cli
• Compiler
• Consistency
• Console
• Database
• Devtools
• Dispatcher
• Dns
• Event
• Eventsource
• Exception
• Fastcgi
• File
• Graph
• Http
• Irc
• Iterator
• Json
• Locale
• Log
• Mail
• Math
• Memory
• Mime
• Model
• Notification
• Praspel
• Promise
• Protocol
• Prototype
• Realdom
• Regex
• Registry
• Router
• Ruler
• Serialize
• Session
• Socket
• Stream
• String
• Stringbuffer
• Test
• Translate
• Tree
• Ustring
• View
• Visitor
• Websocket
• Worker
• Xml
• Xmlrpc
• Xyl
• Zformat
• Zombie
•  

I'm using Propel 1 together with PhpMetrics in a project. The latter requires Hoa, which recently introduced an \EngineException class to emulate a class of the same name in PHP 7. Unfortunately this conflicts with a class of the same name in Propel, and a fatal error results.

What was strange for me was that the code that causes Hoa to load should have no reason to do so - PhpMetrics is a stand-alone project for code analysis, and only that should be loading Hoa. I asked a question about this and someone pointed out that Hoa Core hooks into the "file" load approach in Composer, which means it is always loaded.

For now I have locked to an earlier version of Hoa/Core, and if this no longer works at some point, I can always move PhpMetrics to another repo. However, would it be possible for Hoa to only use an autoloader? I worry that the various functions/classes it creates is dependent on it "force" loading.

Hello :-),

As discussed on the ML, at Apex and on IRC, we are going to drop PHP5.3 in favor of PHP5.4 for the lowest required PHP version. This issue will report new elements and discussions.

Today, it's not possible to call vendor/bin/hoa when Hoa is installed with composer.
This is because in Hoa has no idea that it is installed with composer.
It happens on a Debian (Squeeze and Wheezy), PHP5.4 or PHP5.5
composer is up to date

Fix for this problem, created by Hywan :
#!/usr/bin/env php

Hello :-),

Composer provides a PSR-4 autoloader since several months now. We didn't switch from PSR-0 to PSR-4 in composer.json files because we didn't know how many services are using the latest Composer version. I don't know more right now but I think we can say that we have waited enough time.

Why will it help?

Hoa's autoloader was already PSR-4. We have pointed out the lakes of PSR-0 many times since the origin of PSR-0 but… this is another topic. Anyway, Hoa's autoloader is PSR-4. Consequently, using the same autoloader specification will help to drop specific Composer's code (mainly when accessing to resources). It will help to drop the following code:

• Hoa\Core\Bin\Welcome,
• Hoa\Core\Core,
• Hoa\Core\Protocol\Library.

Modifing all composer.json

We will have to modify all the composer.json files at once and pushing everything at once. This will be like a small rush (potentially around 2-3am to avoid errors). I can create PR for every composer.json files, however, I will start by the one of this library in order to agree on the upcoming patches.

Thoughts?

/cc @hoaproject/hoackers

Most of Hoa's @var tag in property phpDoc don't use the right syntax (according to phpdoc.org & IDEs hints).
The class name shouldn't be written before the var type.

eg:

namespace Hoa\Core\Protocol;

class Protocol {
    /**
     * Collections of sub-components.
     *
     * @var \Hoa\Core\Protocol array
     */
    private $_components   = array();
}

IDEs provide hints for \Hoa\Core\Protocol, but the property is an array...

Hi,

The main hoa file in the Bin folder does not require the autoload from composer properly.

Here is an example.
https://github.com/tomzx/php-semver-checker/blob/master/bin/php-semver-checker