RFC: expectations/assertions

Hi Stas and all,

On Wed, Feb 5, 2014 at 5:29 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

I meant the form of the code, not assert().
JavaScript uses callbacks extensively and users are used to it.
PHP users are also getting used to it since the introduction of closure.

But I mean assert(). Javascript implementations have assert() - Chrome
has it, Firefox has it, NodeJS has it. It does not work like you
propose. Doesn't it make you question your assertion that Javascript
users really need this?

I think it's nice to have as it does not use variable scope/name space.
Code related to assert() is better to hide it's existence as much as
possible. IMO.

JavaScript implementations have different APIs. Node.js has closer API.

assert.throws(
function() {
throw new Error("Wrong value");
},
Error
);

while we may have

assert(
function() {
// Some check here
return FALSE;
},
'Error'
);

I would use at least, since I don't want to assert() related code to use
variable scope nor namespace.

Since I like new assert(), I thought it may help if I explain why I didn't
use assertion.
I have 2 reasons for not using old assert() at all until now.

• Performance: couldn't accept run time overheads
• Scope/Namespace: couldn't accept scope/namespace pollution with complex
  assert.

1st one is the main reason. 2nd one, I may live with it new assert(), but I
do
not want to pollute scope/namespace if it can. It does not make sense to use
scope/namespace for assert() to me. (with complex assertion)

Before the closure introduction, I had to define function. Without
namespace, it's not
a acceptable solution at all. Even with namespace, it's far from
acceptable. Another
option is create_function(), but it's pain to write PHP code as string.
It's not acceptable
also. Closure would be acceptable, but it's not clean as it should be w/o
closure
callback support.

I cannot wait to use new assert(). If it supports closure callback, it's
PERFECT!
I'm really excited about new assert() and I wish desperately it supports
closure
callback. Please add closure callback :)

Thank you!

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki wrote (on 05/02/2014):

JavaScript implementations have different APIs. Node.js has closer API.

[...]

assert(
function() {
// Some check here
return FALSE;
},
'Error'
);

I would use at least, since I don't want to assert() related code to use
variable scope nor namespace.

Actually, if you think this through with a real example, this only makes
sense because of JS's scoping rules, which are very different from PHP's.

A JS closure inherits the whole parent scope by default, and adds
private vars to it, so this would be possible:

function foo(arg)
{
assert ( function() {
var assert_private_var = some_function();
return arg == assert_private_var;
}, 'oops' );
}

In PHP, there is no notion of inherited scope, so this would not work:

function foo($arg)
{
assert ( function() {
$assert_private_var = some_function();
return $arg == $assert_private_var;
}, 'oops' );
}

Since an assertion that can't actually check any state is useless for
anything other than assert(false, 'Should never happen'), you'd always
have to have a use() importing things:

function foo($arg)
{
assert ( function() use ($arg) {
$assert_private_var = some_function();
return $arg == $assert_private_var;
}, 'oops' );
}

That's a lot of boilerplate and room for mistakes, IMHO.

Of course, if we could fix the parser to evaluate functions as soon as
they're defined like in JS, you could make the whole thing into an
expression which would work with the current (and proposed) assert:

function foo($arg)
{
assert ( (function() use ($arg) {
$assert_private_var = some_function();
return $arg == $assert_private_var;
})(), 'oops' );
}

Not pretty, but it would give you your local scope.

Regards,

Rowan Collins
[IMSoP]