"Notporting" Functions

[ylluminate]

With the advent of Node, it seems that many of the "Notporting" functions should now begin implementation. Thoughts?

[brettz9]

Although I think Kevin wanted to make php.js a primarily client-side library, he has always been open to our storing functions in the experimental section (or allowing configuration coordination via the php_js global, so someone could call ini_set() say to specify a server-side environment). So, yes, unless Kevin has objections, I'd say absolutely, at least for adding to the experimental section or adding support via configuration. Though I hope it may be possible to implement with CommonJS (though without knowing much myself, it seems one would have to choose between synchronous and asynchronous APIs?)

[kvz]

Yes I think setting environment and having functions error out if it is not compatible is the way to fly. _workbench can be the workspace for that, _expirimental the place for testing before we move to functions.
it would be nice if we could support asynchronous apis because then you can actually leverage node's power. without it i'm not sure what the benefit would be. we'd have to do this in a consistent manner though, and by e.g. supplying a null callback, a file_exists would work synchronously. If we use the last argument for callbacks then we can be sure normal php code still runs in node so we don't break backwards compatibilty. thoughts?

[kvz]

I'm thinking node.js should be 1st class citizen. I released this npm even though many functions still target browser apis. Hence some uglyness.

But if it where up to me, all things echo default to console.log, all things file default to the fs module. And only if we detect those are not available to we do a stab at browser compatibility.

e.g. using sync ajax for a file_get_contents is just a mistake and allows beginners to do terrible things. But in having it in serverland would allow you to run .php scripts on v8. Which is also terrible, but in a fun way 👯

[brettz9]

FYI, our file_get_contents does support async in a PHP-ish way, via a callback within the context arg:

file_get_contents(fileName, null, {// You can create this "resource" in a more PHP way by calling stream_create_context() here instead
    // stream_options: {http: {}}, // Now optional as in PHP
    stream_params: {
        'phpjs.async': true,
        notification: function () {
            if (this.readyState === 4) {
                alert(this.responseText);
            }
        }
    }
});

...though it is not the most beautiful bird out there: :)

I surmise even the phpjs.async custom arg might not be necessary if the flags STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT were supported here by PHP, but of course that makes it even uglier.

[kvz]

Thanks for reporting, and sorry for the long wait. This project and my motivation were in a bad spot. I recently did a lot of work to breathe new life into it (http://locutus.io/2016/05/announcing-locutus/).

But if it where up to me, all things echo default to console.log, all things file default to the fs module. And only if we detect those are not available to we do a stab at browser compatibility.

This bit made it into Locutus.

But in having it in serverland would allow you to run .php scripts on v8. Which is also terrible, but in a fun way 👯

This goal didn't : )

But the good thing is Node is the primary target platform, with Browserify (and similar) as the recommended way to then target browsers.