You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 26, 2019. It is now read-only.
It will be more convenient if a helper receives an instance of \Handlebars\Arguments instead of arguments string. In this case a helper should know nothing about parsing and just uses already prepared arguments. Also if we parse an arguments string before calling a helper we can guarantee that arguments string is valid.
I could provide a pull request, if the maintainers are interesting in it.
The text was updated successfully, but these errors were encountered:
Its a good idea. But what about BC break? How we can maintain backward compatibility? And if we can not, I think its time to migrate to another branch (develop for example)
\Handlebars\Arguments has magic __toString method. Thus it can be freely used in string context. The only problem is is_numeric function that used directly on arguments string in several places.
is_numeric is a compatibility problem for custom helpers. Here is an example:
$args = '92'; // just stringis_numeric($args); // returns true// The same argument string but wrapped with the class$args = new \Handlebars\Arguments('92');
is_numeric($args); // returns false
It will be more convenient if a helper receives an instance of
\Handlebars\Arguments
instead of arguments string. In this case a helper should know nothing about parsing and just uses already prepared arguments. Also if we parse an arguments string before calling a helper we can guarantee that arguments string is valid.I could provide a pull request, if the maintainers are interesting in it.
The text was updated successfully, but these errors were encountered: