OpenEuphoria

Re: Source changes

• Posted by Pete Lomax <petelomax at blueyon?er.co.uk> Jul 02, 2007
• 640 views

Derek Parnell wrote:
> 
> Comments please...
>
>a new library called "convtext.e" will be added to Euphoria include folder.
Good. A new include file means less impact on legacy code.

The idea of a user-definable callback, like walk_dir()/default_dir() in file.e,
still appeals to me as you can make it dead easy for newbies but still have fine
control for advanced coders.

Did you have any comments on my proposed changes to get.e?
http://palacebuilders.pwp.blueyonder.co.uk/pc.htm
I accept the above is not going to be used, and that instead of passing a
routine_id on every call, an optional set() at the start would be better.

> 
> -- Proposed Routines --
> This set will attempt to convert the text to the requested format, but if
> they are unable to they do not fail, instead they return zero.
> 
>  toInteger(sequence TextIn)  -- converts the text to an integer.
>  toNumber(sequence TextIn)  -- converts the text to an integer or atom as 
>                             -- appropriate.
>  toDigits(sequence TextIn)  -- converts the text to an integer or atom as 
>                             -- appropriate, but disregards all non-digits
>                             -- except the first decimal-separator.
>  toBase(sequence TextIn, integer Base)  -- converts the text to an
>                                         -- integer or atom as appropriate,
>                                         -- but disregards all non-digits as
>                                         -- defined by the 'number-base'
>                                         -- supplied.
Just as an idea, I wonder:
   text_to_data(INTEGER,xxx)
   text_to_data(ATOM,xxx)
   text_to_data(DIGITS,xxx)
   text_to_data({BASE,12},xxx)
Extendable with strings and sequences and dates and times and wotnot that way.

This is also very value()-sided, no equivalent get() routines.


> Those routines will allow for decimal-separators, number-grouping, 
I got lost here. I could't work out if you meant all the routines mentioned in
the post, the ones just above, or the ones after that point. Actually, I think
I'd like to see RDS-style docs for these new routines up front.

>  StringInt( integer Data )
>  StringNumber( atom Data )
>  StringFormat( atom Data, sequence Format)
Without examples I see no gain over sprint(f).

>  DateFormat ( sequence Data, sequence Format)
>  TimeFormat ( atom Data, sequence Format)
>  CurrencyFormat (atom Data)

I would, for example, hope to see in RDS-style docs that DateFormat etc should
only be used for display and reporting purposes; saving data to file should use
the rawest possible format, eg {2007,7,2} not "2nd July 2007", otherwise a user
in a different locale may not be able to read the data.

Regards,
Pete