Re: zend_compare & co

At 15:12 07-10-01, Jeroen van Wolffelaar wrote:

The point is, who's responsability is it for checking wether they are normalized or not? IMO, you shouldn't trust compare and boolean function to be limited to (-1,)0,1, because it is very easy to have !=0 or ==0 in your checks, and <0 and >0. So why unnecessarily trust on -1, 0 or 1 with a greater chance on bugs? And also important, that normalization decreases performance, and for what??

For consistency. It may be easy to have <0 in your code, but it's just as easy as comparing with -1. That, however, would work on certain platforms, but won't work on others, possibly causing code developed under one machine to stop working on another. Normalizing solves that.

About proto'ing Zend functions: where is the plan, the original scheme according to what you programmed Zend? Weren't there proto's in it? I agree with Jani that proto's is the absolute minimum of documentation that should be in a piece of software that's used by means of its API. About the 'do it yourself', I would incidentally add proto's to Zend if I could, with 'correct me if i'm wrong' tags.

I object :) You're welcome to write documentation, but bad documentation is worse than no documentation. Like most other projects (both opensource and not, but especially opensource) - there wasn't any prototype-level documentation before the implementation phase. It worked fairly well too.

At least the very important information like wether or not you can trust on zend booleans to be either 1 or 0 should be clearly documented somewhere... otherwise you're asking for unnecessary bugs. You mention 'robust functions' yourself, and robust means to me that a function can be easily checked to work exactly according to its specification. Implying that there should be some kind of specificiation to start with.

The engine is written in C. Obviously, with full access to every bit of information in the structures, you can't rely on anything being anything, unless people follow the conventions. All the code in the engine follows the convention that booleans should be either 0 or 1. If you're unclear as to what values should be assigned to denote false and true, just use the macros instead. A robust function, by the way, is a function that won't collapse even if it's sent something slightly different from what it expects. What you describe is simply a function that works, there's nothing robust about it... Zeev