Re: [PEPr] -1 for Math::BigInteger

Hello, On Tue, 27 Jun 2006 12:00:53 -0700 joe@joestump.net (Joe Stump) wrote: > > I find it somehow unconstructive (if not destructive) to come up > > with such things in the vote phase. The proposal has been online > > for 2 weeks. CS Issues can be fixed in CVS. > > I'm sorry that nobody looked at this sooner. Anyone from PEAR who > took two minutes to look over the code would notice these glaring > issues (they're not difficult to fix, but glaring nonetheless). > Don't poo poo me for catching them a little late. As they say, better > late than never. Well, not if the pkg gets rejected for CS reasons. > My point probably wasn't clear. In his example script he checks for > a function and then defines it if it's not there. If his package > relies on that function then it should be in the package files and > not the example / userland code. Yes, or it should depend on a more recent php version. > What do you mean by this? I was saying that his class should use > native PHP BC functions if they exist for performance reasons. I > didn't make any mention of PHP versions so I'm a bit confused as to > what you're saying here. I mean to depend on the required php version or implement the function in the package itself (for example like I do in validate for modf) > > It would be nice if further votes (in pepr in general) focus on the > > goal and implementation of a package before voting -1, especially > > when all bad points are about CS, inline docs and PHPCompat. > > It would have been preferable to have people comment during the > earlier phase, but obviously that didn't happen. It's better it's > caught later in the voting phase than not caught at all. Yes, but as I said earlied I would prefer to go "back" to the comment phase, fix the issues to get this package accepted. -- Pierre