From: Nicolas C. <war...@fr...> - 2004-04-26 15:17:24
|
> Since you asked, I have a tiny suggestion for ExtString: > rchop might be even more useful if it had an optional > parameter ~char such that > > ExtString.rchop ~char:'/' s [...] A different function is definitly needed :) Please propose a name so I can add it. > This can be quite useful for "path-type" string > manipulation. > > > The main ones that occur to me are: > > > > Listutil.sub > > This could easily be done if the generalized "enum" > function (as discussed above) were implemented. That's what I was thinking. A lazy sub is possible, although not very interesting (I never used sub on Lists) > > Strutil.strip, lstrip, rstrip > > (These are *not* the same as the chop functions in ExtString) > > I agree that these would be useful. > > > Strutil.split > > (It is defined in terms of Str.split_delim in MissingLib but could > > probably be implemented without it for Extlib) > > This would probably be useful for quick hacks, when you > don't want to pull out the power of Pcre. I agree we need more functions to put into ExtString. > > > > > > * Client-side IMAP library > > This is *definitely* something which is outside the realm > of ExtLib. :) Not completely sure... Having a common set of protocols such as HTTP , IMAP , POP3, FTP into ExtLib is "general use" enough to make it available. Protocols are by definition the things you don't want to reimplement over and over since they're already a standard. > Hmm... it doesn't seem that true async I/O is possible > with the Unix module. However, you *can* do > **non-blocking** I/O by using the select function with a > zero timeout. This has been good enough for me so far -- > and I was actually a bit surprised that the "available" > closure on channels doesn't use this (since it also works > on sockets); perhaps platform availability has something > to do with it? Could you explain more about this ? Regards, Nicolas Cannasse |