Menu
▾
▴
gobo-eiffel-develop
|
From: Colin P. A. <co...@co...> - 2008-01-02 14:15:30
|
I have factored out the core code for the XSLT functions format-date(), format-time() and format-date-time() and moved it into the time library (this introduces dependencies for the time library on the math and regexp libraries, but I think this should not be considered a problem), and added a new function named xslt_formatted to each of DT_DATE, DT_TIME and DT_DATE_TIME. An example of how to call this is present in each of the classes DT_TEST_DATE, DT_TEST_TIME and DT_TEST_DATE_TIME. More examples of the capabilities of the function can be seen in the class DT_TEST_XSLT_FORMAT_DATE_TIME. -- Colin Adams Preston Lancashire |
|
From: Eric B. <er...@go...> - 2008-01-02 19:49:39
|
Colin Paul Adams wrote: > I have factored out the core code for the XSLT functions > format-date(), format-time() and format-date-time() and moved it into > the time library (this introduces dependencies for the time library on > the math and regexp libraries, but I think this should not be > considered a problem), and added a new function named xslt_formatted > to each of DT_DATE, DT_TIME and DT_DATE_TIME. Introducing new dependencies should always be considered as a problem and should be considered with care. My first question is: what does this refactoring bring to the users? I can see that people who don't care about XSLT and XPath will have more classes to compile. Will there be people who will use these new functionalities in the date/time library and not the xslt/xpath libraries? I don't really have time now to review this code that have been added to the date/time library, but just looking at the names of the new classes seems very suspicious to me (DT_XSLT_..., DT_XPATH_...). If it is likely that people who will use these new functionalities will also use the xslt/xpath libraries, then what about having all that in a cluster 'time' in these libraries? Also, I wonder what is peculiar to date/time in class DT_STRING_ROUTINES. Likewise with DT_XSLT_NUMBER_ROUTINES. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-01-02 20:04:48
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Colin Paul Adams wrote:
>> I have factored out the core code for the XSLT functions
>> format-date(), format-time() and format-date-time() and moved
>> it into the time library (this introduces dependencies for the
>> time library on the math and regexp libraries, but I think this
>> should not be considered a problem), and added a new function
>> named xslt_formatted to each of DT_DATE, DT_TIME and
>> DT_DATE_TIME.
Eric> Introducing new dependencies should always be considered as
Eric> a problem and should be considered with care. My first
Eric> question is: what does this refactoring bring to the users?
It gives users powerful formatting capabilities for dates and times.
Eric> I can see that people who don't care about XSLT and XPath
Eric> will have more classes to compile. Will there be people who
Eric> will use these new functionalities in the date/time library
Eric> and not the xslt/xpath libraries?
Yes. That is why I did it.
Eric> now to review this code that have been added to the
Eric> date/time library, but just looking at the names of the new
Eric> classes seems very suspicious to me (DT_XSLT_...,
Eric> DT_XPATH_...).
Perhaps the names are misleading.
The classes named DT_XPATH_* provide features needed by the XPath data
model for times and dates that were not currently in the corresponding
plain DT_* classes. Maybe they could be merged, or maybe I could think
of better names.
The DT_XSLT_* classes are just renamed from XM_XSLT_*.
Eric>If it is likely that people who will use
Eric> these new functionalities will also use the xslt/xpath
Eric> libraries, then what about having all that in a cluster
Eric> 'time' in these libraries?
The refactoring is precisely so you DON'T have to compile the XPath
and XSLT libraries in to your application to get these formatting
routines.
Eric> Also, I wonder what is peculiar
Eric> to date/time in class DT_STRING_ROUTINES.
Yes, that's a bad one. I don't really know what to do with it.
Eric> Likewise with
Eric> DT_XSLT_NUMBER_ROUTINES.
The routines in their are also used by the XSLT format-number()
function. Perhaps it would be better placed in the string library.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2008-01-03 06:56:24
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Colin Paul Adams wrote:
Eric> I can see that people who don't care about XSLT and XPath
Eric> will have more classes to compile. Will there be people who
Eric> will use these new functionalities in the date/time library
Eric> and not the xslt/xpath libraries?
>>
>> Yes.
Eric> Who?
Me for one. I don't want to have to run an XSLT transformation just to
format a date.
And Mauricio thought it was a very good idea, which is why he asked me
to implement it. You have received emails about this haven't you?
>> The refactoring is precisely so you DON'T have to compile the
>> XPath and XSLT libraries in to your application to get these
>> formatting routines.
Eric> But now even if you don't need these functionalities you
Eric> have to compile regexp and math when you use the date/time
Eric> library. Which is better?
The latter, as they are much smaller.
But perhaps there should be a separate formatting library, with a time
cluster within it. I think that makes a lot of sense.
Another thing I have long wanted to do sometime (but not now), is to
generate Eiffel classes from the Common Locale Database Repository
(Unicode CLDR project - see http://www.unicode.org/cldr/), and it
probably makes sense for that to be another cluster in the same library.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2008-01-03 08:57:57
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> I don't understand: why would you need to run an XSLT
Eric> transformation? I'm just talking about putting the
Eric> formatting classes in a cluster in the xslt/xpath library,
Eric> not about using an XSLT transformation.
Well, I can do that, I guess. If that's what you prefer.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-01-03 10:00:02
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> I don't know what I prefer yet. I've been put in front of a > Eric> fact with not prior notice (the date/time library now > Eric> depends on regexp and math) and I'm still trying to > Eric> understand why this was done and whether this was really > Eric> needed. > > I thought it was the natural place for date and time formatting. > But now you've pointed out some disadvantages, I think a separate > formatting library might be better. Not necessarily. What bothers me is that it looks like using a power drill to kill a fly. Why does it need to use regexp and math? Why does it need auxiliary classes like that? As I said I don't really have time to review the code now, but I guess I will have to do that anyway if I want to fully understand ;-( -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-01-03 15:57:18
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> I definitely don't have time to review it now. So what I
Eric> suggest is that we let it like that for the time being so
OK.
Sorry about the lack of notice. It didn't occur to me that 13 December
would be too late (but I should have posted something here anyway, for
others to see the proposal).
Eric> that I can propagate the change to AXAR without further
Eric> delay, and I will have a closer look at it later when time
Eric> permits (ideally before the next release of Gobo).
Note that there is a call in DT_DATE/DT_TIME and DT_DATE_TIME to wrap
the details of calling the formatter. So either the review MUST be
done before the next release of Gobo (as this will drag everyhting
inno matter where the rest moves to), or I could comment those calls
out now, with a note that this is under review.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-01-03 16:18:19
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> I definitely don't have time to review it now. So what I > Eric> suggest is that we let it like that for the time being so > > OK. > Sorry about the lack of notice. It didn't occur to me that 13 December > would be too late (but I should have posted something here anyway, for > others to see the proposal). I must admit that I didn't see your ticket in the Helpdesk until yesterday. Was I in the notification list before that? Anyway, I'm fine with what is mentioned in the ticket. What I find annoying is the addition of library dependencies and the use of auxiliary classes for something that may look very simple at first (e.g. display a date/time in a given format). And yes, modifications in Gobo should be discussed primarily in the Gobo mailing lists. Gobo is not an AXAR project. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-01-06 10:28:43
|
>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
Colin> I can eliminate the regular expression without too much
Colin> trouble.
I've done that now.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2008-01-06 15:59:16
|
>>>>> "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.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2008-01-06 16:20:24
|
>>>>> "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 (so I
might as well forget about removing the dependency on math, although I
will still do it if I can, as it slows down execution a lot).
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2008-01-07 06:28:59
|
>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
Colin> But after looking at the appendix to the XSLT
Colin> recommendation, I see that an implementation is allowed to
Colin> specify a maximum number that can be formatted. And as I
Colin> can't see any practical use cases for formatting larger
Colin> numbers than can be represented by INTEGER (the intended
Colin> use case for xsl:number is for formatting section
Colin> numbering, and the like), I shall have a go at eliminating
Colin> the use of MA_DECIMAL.
I got my requested clarification from the working group - the limit
only applies if the range of xs:integer is limited by the
implementation.
And it was to avoid doing this that we introduced MA_DECIMAL into Gobo
in the first place.
So it will have to stay.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-01-07 09:49:31
|
Colin Paul Adams wrote: > I got my requested clarification from the working group - the limit > only applies if the range of xs:integer is limited by the > implementation. > And it was to avoid doing this that we introduced MA_DECIMAL into Gobo > in the first place. I don't think that MA_DECIMAL has been introduced into Gobo to accommodate xs:integer ;-) -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-01-02 20:52:41
|
Colin Paul Adams wrote: > Eric> I can see that people who don't care about XSLT and XPath > Eric> will have more classes to compile. Will there be people who > Eric> will use these new functionalities in the date/time library > Eric> and not the xslt/xpath libraries? > > Yes. Who? > Eric>If it is likely that people who will use > Eric> these new functionalities will also use the xslt/xpath > Eric> libraries, then what about having all that in a cluster > Eric> 'time' in these libraries? > > The refactoring is precisely so you DON'T have to compile the XPath > and XSLT libraries in to your application to get these formatting > routines. But now even if you don't need these functionalities you have to compile regexp and math when you use the date/time library. Which is better? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-01-07 09:50:34
|
Colin Paul Adams wrote: > I got my requested clarification from the working group - the limit > only applies if the range of xs:integer is limited by the > implementation. > And it was to avoid doing this that we introduced MA_DECIMAL into Gobo > in the first place. BTW, how come we need such big numbers to format dates? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-01-03 08:46:12
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Colin Paul Adams wrote: > Eric> I can see that people who don't care about XSLT and XPath > Eric> will have more classes to compile. Will there be people who > Eric> will use these new functionalities in the date/time library > Eric> and not the xslt/xpath libraries? > >> > >> Yes. > > Eric> Who? > > Me for one. I don't want to have to run an XSLT transformation just to > format a date. I don't understand: why would you need to run an XSLT transformation? I'm just talking about putting the formatting classes in a cluster in the xslt/xpath library, not about using an XSLT transformation. > And Mauricio thought it was a very good idea, which is why he asked me > to implement it. You have received emails about this haven't you? I was on vacation. But still, I don't see the point in introducing new dependencies in the date/time library. At AXAR the whole Gobo library is compiled anyway. So the classes to format a date would be available even when located in a cluster of the xslt/xpath library. No new dependency added. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-01-07 13:43:08
|
Colin Adams wrote: > > > On 07/01/2008, *Eric Bezault* <er...@go... > <mailto: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. And is it that much code duplication to implement the formatting rules both for an INTEGER and for a MA_DECIMAL as input? 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. Code duplication is one thing, but wasting execution time to convert entities in one way or another just for the sake of avoiding code duplication (and introducing library dependencies during that process) in another thing that is not necessarily better. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-01-03 09:09:44
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> I don't understand: why would you need to run an XSLT > Eric> transformation? I'm just talking about putting the > Eric> formatting classes in a cluster in the xslt/xpath library, > Eric> not about using an XSLT transformation. > > Well, I can do that, I guess. If that's what you prefer. I don't know what I prefer yet. I've been put in front of a fact with not prior notice (the date/time library now depends on regexp and math) and I'm still trying to understand why this was done and whether this was really needed. One thing that bothers me is that it adds so many auxiliary classes just for this formatting. And is the use of regexp and math really necessary? One other thing that should be considered when working on a small library like date/time that can be used everywhere is to be careful not to create too many temporary objects. This library can be use in a system with no GC, or in a system already using a lot of memory. In the latter case, reducing the load of work on the GC may have a significant impact on performance. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-01-07 14:20:05
|
Colin Adams wrote: > On 07/01/2008, *Eric Bezault* <er...@go... > <mailto: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. What impact would it have on the integers held in a date? Would they use other unicode characters for the digits? > 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? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-01-03 09:33:57
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> I don't know what I prefer yet. I've been put in front of a
Eric> fact with not prior notice (the date/time library now
Eric> depends on regexp and math) and I'm still trying to
Eric> understand why this was done and whether this was really
Eric> needed.
I thought it was the natural place for date and time formatting.
But now you've pointed out some disadvantages, I think a separate
formatting library might be better.
Eric> One thing that bothers me is that it adds so many auxiliary
Eric> classes just for this formatting. And is the use of regexp
Eric> and math really necessary?
I can eliminate the regular expression without too much trouble. It's
only used in one place. Eliminating the use of MA_DECIMAL will be much
harder - it can be done, but not without duplicating a lot of code.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-01-03 15:45:27
|
Eric Bezault wrote: > Colin Paul Adams wrote: >>>>>>> "Eric" == Eric Bezault <er...@go...> writes: >> >> Eric> I don't know what I prefer yet. I've been put in front of a >> Eric> fact with not prior notice (the date/time library now >> Eric> depends on regexp and math) and I'm still trying to >> Eric> understand why this was done and whether this was really >> Eric> needed. >> >> I thought it was the natural place for date and time formatting. >> But now you've pointed out some disadvantages, I think a separate >> formatting library might be better. > > Not necessarily. What bothers me is that it looks like using > a power drill to kill a fly. Why does it need to use regexp > and math? Why does it need auxiliary classes like that? > As I said I don't really have time to review the code now, > but I guess I will have to do that anyway if I want to fully > understand ;-( I definitely don't have time to review it now. So what I suggest is that we let it like that for the time being so that I can propagate the change to AXAR without further delay, and I will have a closer look at it later when time permits (ideally before the next release of Gobo). -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-01-06 11:20:19
|
>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
Colin> Eliminating the use
Colin> of MA_DECIMAL will be much harder - it can be done, but not
Colin> without duplicating a lot of code.
The need was because the code is also used by the implementation of
xsl:number (formatting dates and times are already limited to INTEGER
by virtue of DT_DATE using INTEGER for the year).
But after looking at the appendix to the XSLT recommendation, I see
that an implementation is allowed to specify a maximum number that can
be formatted. And as I can't see any practical use cases for
formatting larger numbers than can be represented by INTEGER (the
intended use case for xsl:number is for formatting section numbering,
and the like), I shall have a go at eliminating the use of MA_DECIMAL.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2008-01-06 15:56:18
|
>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
Colin> But after looking at the appendix to the XSLT
Colin> recommendation, I see that an implementation is allowed to
Colin> specify a maximum number that can be formatted.
Unfortunately this appendix is non-normative. There may or may not be
a contradiction with the body of the recommendation. I am seeking a
ruling from the working group.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-01-06 15:53:41
|
Colin Paul Adams wrote: >>>>>> "Colin" == Colin Paul Adams <co...@co...> writes: > > Colin> I can eliminate the regular expression without too much > Colin> trouble. > > I've done that now. OK, thanks. Note that I had already started the process necessary to check-in the snapshot of Gobo at AXAR. Do you want me to start again from scratch? It's not a big deal for me, it's just that it would delay the process by one day or so. Just let me know. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-01-06 15:55:06
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Colin Paul Adams wrote:
>>>>>>> "Colin" == Colin Paul Adams <co...@co...>
>>>>>>> writes:
>>
Colin> I can eliminate the regular expression without too much
Colin> trouble.
>>
>> I've done that now.
Eric> OK, thanks.
Eric> Note that I had already started the process necessary to
Eric> check-in the snapshot of Gobo at AXAR. Do you want me to
Eric> start again from scratch? It's not a big deal for me, it's
Eric> just that it would delay the process by one day or so. Just
Eric> let me know.
No it doesn't make any difference. The next check-in will just remove
the dependency silently, and won't make any difference.
--
Colin Adams
Preston Lancashire
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X