The introduction of the Calendar types and the %Calendar struct is really
helpful. Its also helpful that the @behaviour doesn't enforce using the
struct..
In several industries the idea of an annual calendar has either a fixed
starting date or has a "day of week" starting date. For example, a
calendar may have a year defined as "starts on the last Friday of June" or
"end of the last Tuesday in December". Or more simply "Starts on July
1st". Whilst it would be possible to define a Calendar module for each of
the possible variations it quickly becomes impractical. They are more akin
to configuration to be applied in the context of a module that handles, for
example, My.Calendar.FourFourFive or My.Calendar.FiscalYear.
Even the Calendar.ISO module in Elixir has some ambiguity since ISO 8601
defines an "ISO week number" (the week with the first Thursday in it)
whereas a Gregorian calendar would assume that the first week starts with
January 1st. Maybe thats more a naming issue than configuration but
configuration could also help here.
Therefore I wonder if the Calendar struct itself would benefit from having
a `meta` element with default `nil` that Calendar authors could use for
configuration information. For my simple example, My.Calendar.FiscalYear
might use it to store `%{starts: {7, 1}}`. `For My.Calendar.FourFourFive`
is might be `%{starts: :last:, day_of_week: 5, month: 6}`
Benefits:
A Calendar strategy can be build for a class of calendar types commonly in
use and configuration is passed around at the same time as the Calendar
Module name
Downside:
Duplication of configuration in potentially lots if places.
Perhaps there is another approach for managing configuration? Passing
around the Module name is of course cheap since its just an atom.
Arbitrary configuration potentially is much more overhead depending on the
content.
On Tuesday, March 15, 2016 at 11:28:31 PM UTC+11, José Valim wrote:
>
> Hello everyone,
>
> I am glad to say we are introducing Calendar types into Elixir to make
> integration between all the different libraries simpler. You can see the PR
> here: https://github.com/elixir-lang/elixir/pull/4383. Feedback is
> welcome regarding the struct definitions.
>
> In the following months, we will be augmenting those modules and adding
> some basic functions. Although expect the heavy work, specially if it comes
> to timezone support and more, to be done in the separated libraries.
>
> Thank you!
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/e51829a8-918c-489b-8a29-e85c7f1d79e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
