gobo-eiffel-develop

Re: [gobo-eiffel-develop] Date/time formatting

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>  I shall have a go at eliminating the use of MA_DECIMAL.

Great. Also note that my experience, running the Gobo bootstrap
and test suite with ISE, showed that in addition to regexp and
math, the date/time library now also depends on library/string
and library/structure.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Date/time formatting

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >> I shall have a go at eliminating the use of MA_DECIMAL.
> 
>     Eric> Great. Also note that my experience, running the Gobo
>     Eric> bootstrap and test suite with ISE, showed that in addition
>     Eric> to regexp and math, the date/time library now also depends
>     Eric> on library/string and library/structure.
> 
> Well this isn't new. If you look at the system.xace in the test/time
> directory, you will see quite a few dependencies. 
> Mind you, some of them may just be for the test framework.

Yes, there are for the test framework. I had to add them in
example/time/clock.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Date/time formatting

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     >> Well this isn't new. If you look at the system.xace in the
>     >> test/time directory, you will see quite a few dependencies.
>     >> Mind you, some of them may just be for the test framework.
> 
>     Eric> Yes, there are for the test framework. I had to add them in
>     Eric> example/time/clock.
> 
> Well, I won't be able to remove any dependency on structure 

Do you know where this dependency on structure comes from?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Date/time formatting

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    >> Well, I won't be able to remove any dependency on structure

    Eric> Do you know where this dependency on structure comes from?

 DT_XSLT_FORMAT_DATE_TIME:

Lots of use of DS_CELL for passing arguments. These could be changed
to KL_CELL.
Two uses of ST_SPLITTER/DS_LIST for parsing values (that seems to be
the string library).
Since the splitting is only on a single character, I guess it wouldn't
be a big job after all to remove this, BUT:

DT_XSLT_NUMBER_ROUTINES:
 This has string/unicode dependencies only - these are vital, and
 can not be removed.
And including this library is a much larger overhead than anything
 else we have been talking about.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Date/time formatting

[Colin A. <col...@go...>]

On 07/01/2008, Eric Bezault <er...@go...> wrote:
>
>
> BTW, how come we need such big numbers to format dates?
>
> We don't.
But the code is shared by xsl:number (as the formatting rules are defined to
be the same), which might format any number.

Re: [gobo-eiffel-develop] Date/time formatting

[Colin A. <col...@go...>]

On 07/01/2008, Eric Bezault <er...@go...> wrote:
>
> Colin Adams wrote:
>
> > But the code is shared by xsl:number (as the formatting rules are
> > defined to be the same), which might format any number.
>
> And is it that much code duplication to implement the formatting
> rules both for an INTEGER and for a MA_DECIMAL as input?


Unfortunately, yes, it is (I did have a look into this).
What is more, it will get worse in the future - so far there is only an
English language version. There will be more.


It sounds to me as if because when written to a file an integer
> and a decimal look the same we should first convert INTEGERs to
> MA_DECIMALs when passing them to class FILE.


Now you've lost me.

Re: [gobo-eiffel-develop] Date/time formatting

[Colin A. <col...@go...>]

On 07/01/2008, Eric Bezault <er...@go...> wrote:
>
> Colin Adams wrote:
>
> > Unfortunately, yes, it is (I did have a look into this).
> > What is more, it will get worse in the future - so far there is only an
> > English language version. There will be more.
>
> What impact would it have on the integers held in a date?
> Would they use other unicode characters for the digits?


That is already possible even for the English language version.
The main significance of language is if you choose  word output.
E.g. Two Thousand and Seven (rather than 2007).


>     It sounds to me as if because when written to a file an integer
> >     and a decimal look the same we should first convert INTEGERs to
> >     MA_DECIMALs when passing them to class FILE.
> >
> >
> > Now you've lost me.
>
> In other words, for anything I want to do in an INTEGER, why
> would I need to convert it to a MA_DECIMAL first? If I dpn't
> do this conversion for anything I do with an INTEGER, why should
> it be different in this particular case?



OK. I understand your point now.
I did think at the weekend about making it a generic parameter (constrained
to a descendant of NUMERIC), but then I got side-tracked by the possibility
of eliminating MA_DECIMAL altogether.

I will investigate this at the weekend.

Re: [gobo-eiffel-develop] Date/time formatting

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Adams <col...@go...> writes:

    Colin> OK. I understand your point now.  I did think at the
    Colin> weekend about making it a generic parameter (constrained to
    Colin> a descendant of NUMERIC), but then I got side-tracked by
    Colin> the possibility of eliminating MA_DECIMAL altogether.

    Colin> I will investigate this at the weekend.

I've reviewed DT_XSLT_NUMBERER_EN to see whether this is possible.

The main problem seems to be the use of
{MA_DECIMAL}.is_integer/to_integer as NUMERIC doesn't have these.

The use of {MA_DECIMAL}.to_scientific_string is also an issue - but it
is probably non-conformant as it is.

I can eliminate MA_DECIMAL quite easily by using a new deferred class
which will have two descendants, one based on INTEGER_64 or
INTEGER_32, and one based on MA_DECIMAL.

But you are already unhappy about the use of auxiliary classes.

And I definitely can't eliminate the unicode library usage.
-- 
Colin Adams
Preston Lancashire