On Mon, Feb 3, 2014 at 9:38 AM, Stas Malyshev <[email protected]> wrote:
> Hi!
>
>> Well lets not forget that we already have an implementation as part of
>> the core, so to argue that we don't require assert in the core is moot;
>> we already have it.
>
> I'm not sure what you mean. We have assert function, a function among
> others. What you propose is special engine-level magic just for this
> function. The difference is like having a program that runs on Linux and
> does X and having special patch in Linux kernel just to do X. The bar
> for the latter is much higher.
>
>> While you can avoid some overhead in userland, you cannot remove the
>> overhead completely; a good assertion API should have no impact on
>> production, none, it should require no boilerplate code to make sane use
>> of it, at all, since it is meant to be a core feature.
>
> This is not completely fulfilled by your patch either - it still has an
> overhead of having the opcodes there and doing the jumps. If the code
> you're avoiding to run is heavy, then of course this overhead is
> negligible compared to the code you're avoiding, but the same then is
> true for purely userspace solution.
>
>> It would seem to create inconsistency, but only because it's compatible
>> with legacy code asserting strings, if you are smart, you will not
>
> It doesn't "seem" to create inconsistency. It creates it. It's not like
> I'm imagining two parameters doing the same thing :)
>
>> assert with strings and take advantage of the new implementation, if you
>> are not, you will continue to assert strings and be unaffected by the
>> new implementation ... that seems ideal to me, and Dmitry ...
>
> I don't think having a function that is half a function and half a magic
> engine constraint and that is controlled by two separate settings, one
> living in zend. and one in assert. is really ideal. Also, it is not true
> that string parameter is the only thing that controls it - as I already
> showed, how you call it also makes it work completely different and
> assert.* parameters still influence it even in magic mode, leading to
> such things as both throwing exceptions and bailing out - which I still
> don't understand how it's supposed to work.
I fully agree here.
As the effort to reduce the impact of assert in production is much
appreciated I do not see much needs for this "addition".
I also discussed with a couple of developers being intensively
involved in testing tools and framework for php and the consensus is
that they do not need it for the large majority. A minority even
considers this feature as not really good, assert never was a good
thing to use (I never used for example).
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org