Aug 3 2015
Jul 22 2015
For a long time I haven't commented on this, because I haven't had any clear ideas or suggestions. Now I have some thoughts. I don't know how relevant it may be (and I don't know your plans in more detail), but here's some ideas, for whatever it's worth. It will be interesting to see how this develops.
Jul 2 2015
Related HHVM error log message:
Jun 29 2015
Jun 16 2015
I've now also checked and yes, it works in Zend PHP.
Jun 12 2015
May 28 2015
May 19 2015
I've been thinking about it, but not sure what's best. Some thoughts on various options:
May 17 2015
May 4 2015
Apr 30 2015
I found one bug: PhpTagsException::isFatal() is always false for a HookException, because $this->code is only set according to the error level in the __toString() method. I made change 207888 to solve this, using a small redesign (which seemed the simplest solution). I don't know if the redesign is the way you would prefer to solve it.
Apr 13 2015
It's just an idea to make some code in PhpTags extensions shorter. (It can be simpler to exit a hook by throwing an exception. But currently, throwing instead of pushing will stop the runtime.) It's up to you whether it is worth adding support for this.
Apr 11 2015
The new INFO_ORIGINAL_FULL_NAME is even more convenient. :)
Apr 9 2015
Apr 8 2015
I've thought more about PhpTags Functions, which is the one extension among those you are considering that I didn't mention.
Apr 7 2015
Apr 3 2015
Apart from listing objects, constants, etc., a special page could also provide documentation directly in the wiki. Something similar to the current Reference pages for PhpTags Wiki and PhpTags SMW would be possible to generate automatically from the JSON files.
Merging could also be partial, instead of none or all. For example:
- If you add data storage and querying in PhpTags itself, then maybe some PhpTags Wiki features would also make sense to have. (Support for categories, for example.) But there may still be things in PhpTags Wiki that are "extra" features and can be kept separate.