Re: zend_compare & co

On Sun, 7 Oct 2001, Zeev Suraski wrote: > 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. Okay. So normalization should be done, that's okay. But code should NOT rely on that, since it can't rely on compare and boolean functions to be normalized in all cases. It is virtually impossible to have everything normalized, so I think nowhere there should be trusted on the normalization thing. > >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 If you mean incorrect, I agree. Otherwise, I don't. Though good documentation beats them both in any case... > and not, but especially opensource) - there wasn't any prototype-level > documentation before the implementation phase. It worked fairly well too. I agree it works fairly well. But I must say that _from my experience_ starting with implementation before any kind of modelling-to-near-function level (which can be considered a rough form of documentation) is disasterous for the number of bugs in the code. > >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 Which conventions? Where are they? I tried the Zend API docs, but couldn't find them. > 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. Such as ZEND_BOOL(zval, value)? But that macro's doesn't normalize... > 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... Okay, you're right. But a functions needs to work first before possibly becoming robust, or not? > Zeev --Jeroen Jeroen van Wolffelaar Jeroen@A-Eskwadraat.nl http://www.A-Eskwadraat.nl/~jeroen