How useful to whom? There are a lot of modules in Pike (core distribution) which are unuseable for ages, but they are still there, while new things (and really usefull) are accepted extremely seldom (it took ages before Bz2 module appeared in core, for instance).
You are taking the wrong aproach here. Modules doesn't appears. They are checked in by someone. Someone thought that there should be a Bz2 module, and now there is.
You can not (well, you can, but that would be crazy big time) compare modules, that are dynamically loaded once someone is interested in using them, with core language changes that breaks all existing Pike code known to man (your suggestions tend to fall in this category).
The most hard argument against PCRE was that it doesn't support wide strings (while original Regexp does not support those too, even worse, I can't use it to match a _position_ of matching expression).
Now you are confusing Pike-managed-by-Roxen with Pike-managed-by-IDA. More importantly you are confusing Pike-development-funded-by-Roxen with Pike-development-not-funded-at-all. Check in a working PCRE module (I've made place for it in Regexp.PCRE) and see if we get mad or not.
Well... This is weird... I didn't mean to start all this over again, it just turned out... May be later it will be better...
I'm pretty sure you get kicks out of this. Why else...
/ Martin Nilsson (saturator)
Previous text:
2003-09-19 03:16: Subject: Re: float type weirdness
On Fri, Sep 19, 2003 at 02:20:01AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
Could you at least present a workable suggestion before you whine about that nobody likes what you are doing.
I did. It is all in this this thread.
x == x.0 is a good idea in theory, but once x gets to big you'll lose precision and you'll end up with buggy code.
Once I disable auto-bignums this leads to the same problem, but with integers. Where is the difference?
Since neither of us likes code features that hides errors or downright promotes buggy code we can't stop here.
A lot of features in Pike (and especially in standard modules) are so non-intuitive (and so dependent on developer's knowledge and experience) that it makes this very weak argument. One day I'll count those...
One suggestion of yours is to introduce loss-of-precision exception.
This is standard way. Since exceptions are rare, it makes no bad.
Exceptions are generally a bad thing and should be kept to a minimum and reserved for truely exceptional circumstances.
The application must be designed to avoid any exceptions where possible, but this doesn't mean that exceptions are bad thing - simply because they help to develop exception-free application. So simple.
Loss of precision exception is truly exceptional circumstance. At least it is more truly than:
my_error( "No argument to option "+opt+".\n", throw_errors );
in Getopt (and a lot of similar places).
developed, idea that others share) it is better to acknoledge the fact that floats are inprecise and thus never "equal" to an integer.
Integers are inprecise too. They are only 32bits (or 64, but anyway).
IMPORTANT NOTE: If you would like to help develop Pike, please do. Write code and show to us how useful it is.
How useful to whom? There are a lot of modules in Pike (core distribution) which are unuseable for ages, but they are still there, while new things (and really usefull) are accepted extremely seldom (it took ages before Bz2 module appeared in core, for instance). The most hard argument against PCRE was that it doesn't support wide strings (while original Regexp does not support those too, even worse, I can't use it to match a _position_ of matching expression).
Well... This is weird... I didn't mean to start all this over again, it just turned out... May be later it will be better...
Regards, /Al
/ Brevbäraren