OpenEuphoria

Re: Include file such as 'compare.e' or 'find.e'

• Posted by CChris <christian.cuvier at agricultu?e.gouv.?r> Aug 06, 2007
• 581 views

Salix wrote:
> 
> Juergen Luethje wrote:
> > > the functions
> > - find_least()
> > - find_greatest()
> > - least()
> > - greatest()
> > - lesser()
> > - greater()
> > are not special math functions.
> 
> I'm sorry that the functions are not
> - find_min()
> - find_max()
> - min()
> - max()
> They would look much nicer.
> 
> As of the original question: 
> I would vote to keep them in math.e
> That's where I would try to find them first.
> 
> Instead of a long list of find functions such as 
> find_all(), find_any(), find_word(), soundex_find(), etc. 
> I would recommend something like cutom_find()! (Similarly 
> to custom_sort().) 
> 
> Regards,
> 
> Salix

That is exactly what I have tried to do with find_bounds(), but that seems to be
a minority view.

When I wrote locate.e for the ESL, I started out with special names like
find_if(), find_any() and such. Then, as I realised that the number of such
functions would grow out of what a standard user would memorise, I started from
scratch and have a few functions that handle special, supposedly frequent cases,
and a generic_locate() with all kinds of options which don't make it necessary to
know all 57 string functions in the std C library (or 73, cant remember).
Specialised routines are faster and shorter, but they lead to the problem of
being just too many.

As for the min/max names, they were seen by some as ambiguous. The current names
are more precise; they may be a problem to tose whose mastery of english is
minimal.

As for the location, I think misc.e is an even more natural place to look for
these routines than math.e. Yet the latter is still better than having yet
another include file.

CChris