Improving API of Date, Month....
Locked
 
|
Hi
I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor Do I imply something strange or silly? I think that it would make sense to add them. Stef |
|
|
https://pharo.fogbugz.com/f/cases/17098/Improve-Date-class-API
Le 24/11/15 15:59, stepharo a écrit : > Hi > > I was reading the code of Date and I was expecting to get some methods > such as > monthNames > dayNames > daysInMonths > > Ok they are stored in ChronologyConstants but they are not accessible. > There is no monthNames nor > > Do I imply something strange or silly? > I think that it would make sense to add them. > > Stef > > |
Re: Improving API of Date, Month....
|
|
In reply to this post by stepharo
Hi,
I also had an idea for a method which returns the most significant unit of a Duration. For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and it would return you "432 days" (or just “1 year”). I encountered this when wanting to create a time indication on e.g. a commit or a comment. It’s much more readable and user-friendly than a timestamp. Would this be a nice addition to the Duration API? > On Nov 24, 2015, at 3:59 PM, stepharo <[hidden email]> wrote: > > Hi > > I was reading the code of Date and I was expecting to get some methods such as > monthNames > dayNames > daysInMonths > > Ok they are stored in ChronologyConstants but they are not accessible. > There is no monthNames nor > > Do I imply something strange or silly? > I think that it would make sense to add them. > > Stef > |
Re: Improving API of Date, Month....
|
|
In reply to this post by stepharo
2015-11-24 11:59 GMT-03:00 stepharo <[hidden email]>:
> Hi > > I was reading the code of Date and I was expecting to get some methods such > as > monthNames > dayNames > daysInMonths > > Ok they are stored in ChronologyConstants but they are not accessible. > There is no monthNames nor > > Do I imply something strange or silly? > I think that it would make sense to add them. It makes sense, maybe the class Date is not the best for those methods, but there isn't a "Calendar" like class either. Whatever is chosen, it should collaborate with the Locale, but be able to use any other locale to retrieve the names. Esteban A. Maringolo |
Re: Improving API of Date, Month....
|
|
In reply to this post by Skip Lentz-2
2015-11-24 12:14 GMT-03:00 Skip Lentz <[hidden email]>:
> Hi, > > I also had an idea for a method which returns the most significant unit of a Duration. > > For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and > it would return you "432 days" (or just “1 year”). I encountered this when wanting to create > a time indication on e.g. a commit or a comment. It’s much more readable and user-friendly > than a timestamp. > > Would this be a nice addition to the Duration API? It would be nice to have. But why not something like a DurationFormatter? that in turn collaborates with the Locale to ge the words for "Year, Month, Week" in the current language. Regards! |
Re: Improving API of Date, Month....
|
In reply to this post by stepharo
Yes, I badly need to get it localised
I added class accessors to ChronologyConstants to modify month and day names. Hilaire Le 24/11/2015 15:59, stepharo a écrit : > Hi > > I was reading the code of Date and I was expecting to get some methods > such as > monthNames > dayNames > daysInMonths > > Ok they are stored in ChronologyConstants but they are not accessible. > There is no monthNames nor > > Do I imply something strange or silly? > I think that it would make sense to add them. > > Stef > > -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu |
|
|
In reply to this post by Esteban A. Maringolo
Hi guys
I made the mistake to think that it was a good move to improve and make the core more full (and complex in the past). Now what I would love is the following. - keep and reduce if necessary the core date classes (only used internally by the system) - have nice packages that we can load to represent time / calendar -- chronos -- aconcagua -- or a new one That do it the right way: with locale and so on. Why? because it can be complex and verbose and we want to have a small core (for many different reasons). About the durationFormatter I think that we should definitively have more strategies to represent dates and other within a nice date/calendar package. I would love that someone propose something to get the nice extensible Calendar/Date package Stef Le 24/11/15 16:25, Esteban A. Maringolo a écrit : > 2015-11-24 12:14 GMT-03:00 Skip Lentz <[hidden email]>: >> Hi, >> >> I also had an idea for a method which returns the most significant unit of a Duration. >> >> For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and >> it would return you "432 days" (or just “1 year”). I encountered this when wanting to create >> a time indication on e.g. a commit or a comment. It’s much more readable and user-friendly >> than a timestamp. >> >> Would this be a nice addition to the Duration API? > It would be nice to have. But why not something like a > DurationFormatter? that in turn collaborates with the Locale to ge the > words for "Year, Month, Week" in the current language. > > Regards! > > |
|
|
I don’t know chronos, but Chalten (the Aconcagua date API) is quite nice (overuse of globals, IMO, but you gain a lot of expressivity).
Esteban > On 24 Nov 2015, at 18:34, stepharo <[hidden email]> wrote: > > Hi guys > > I made the mistake to think that it was a good move to improve and make the core more full (and complex in the past). > Now what I would love is the following. > > - keep and reduce if necessary the core date classes (only used internally by the system) > - have nice packages that we can load to represent time / calendar > -- chronos > -- aconcagua > -- or a new one > > That do it the right way: with locale and so on. > Why? because it can be complex and verbose and we want to have a small core (for many different reasons). > About the durationFormatter I think that we should definitively have more strategies to represent dates and other > within a nice date/calendar package. > > I would love that someone propose something to get the nice extensible Calendar/Date package > > Stef > > Le 24/11/15 16:25, Esteban A. Maringolo a écrit : >> 2015-11-24 12:14 GMT-03:00 Skip Lentz <[hidden email]>: >>> Hi, >>> >>> I also had an idea for a method which returns the most significant unit of a Duration. >>> >>> For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and >>> it would return you "432 days" (or just “1 year”). I encountered this when wanting to create >>> a time indication on e.g. a commit or a comment. It’s much more readable and user-friendly >>> than a timestamp. >>> >>> Would this be a nice addition to the Duration API? >> It would be nice to have. But why not something like a >> DurationFormatter? that in turn collaborates with the Locale to ge the >> words for "Year, Month, Week" in the current language. >> >> Regards! >> >> > > |
Re: Improving API of Date, Month....
|
|
I agree with Esteban on Chalten. Chalten currently loads on Pharo 4 and 5 without any issue. It has a lots of tests cases that help a lot to learn about it. On Thu, Nov 26, 2015 at 8:55 AM, Esteban Lorenzano <[hidden email]> wrote: I don’t know chronos, but Chalten (the Aconcagua date API) is quite nice (overuse of globals, IMO, but you gain a lot of expressivity). |
|
|
In reply to this post by EstebanLM
> I don’t know chronos, but Chalten (the Aconcagua date API) is quite nice (overuse of globals, IMO, but you gain a lot of expressivity). yes it was with it in mind that I wrote the mail. So I would imrpove the date printer and key our kernel small STef > > Esteban > >> On 24 Nov 2015, at 18:34, stepharo <[hidden email]> wrote: >> >> Hi guys >> >> I made the mistake to think that it was a good move to improve and make the core more full (and complex in the past). >> Now what I would love is the following. >> >> - keep and reduce if necessary the core date classes (only used internally by the system) >> - have nice packages that we can load to represent time / calendar >> -- chronos >> -- aconcagua >> -- or a new one >> >> That do it the right way: with locale and so on. >> Why? because it can be complex and verbose and we want to have a small core (for many different reasons). >> About the durationFormatter I think that we should definitively have more strategies to represent dates and other >> within a nice date/calendar package. >> >> I would love that someone propose something to get the nice extensible Calendar/Date package >> >> Stef >> >> Le 24/11/15 16:25, Esteban A. Maringolo a écrit : >>> 2015-11-24 12:14 GMT-03:00 Skip Lentz <[hidden email]>: >>>> Hi, >>>> >>>> I also had an idea for a method which returns the most significant unit of a Duration. >>>> >>>> For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and >>>> it would return you "432 days" (or just “1 year”). I encountered this when wanting to create >>>> a time indication on e.g. a commit or a comment. It’s much more readable and user-friendly >>>> than a timestamp. >>>> >>>> Would this be a nice addition to the Duration API? >>> It would be nice to have. But why not something like a >>> DurationFormatter? that in turn collaborates with the Locale to ge the >>> words for "Year, Month, Week" in the current language. >>> >>> Regards! >>> >>> >> > > |
|
|
In reply to this post by HilaireFernandes
> Yes, I badly need to get it localised > I added class accessors to ChronologyConstants to modify month and day > names. but this is dangerous because you do not know the assumption that the system is doing. I would go more in improving chalten > > Hilaire > > Le 24/11/2015 15:59, stepharo a écrit : >> Hi >> >> I was reading the code of Date and I was expecting to get some methods >> such as >> monthNames >> dayNames >> daysInMonths >> >> Ok they are stored in ChronologyConstants but they are not accessible. >> There is no monthNames nor >> >> Do I imply something strange or silly? >> I think that it would make sense to add them. >> >> Stef >> >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |