[elixir-core:7263] Re: [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

2017-07-10 Thread Wiebe-Marten Wijnja 
I am all for this!

However, I do have a note about the week-related stuff: 
On one hand, people might expect 'weeks' to be readily available 
(`:calendar` offers them, and many other libraries in other language 
environments do). 
On the other, many calendars do not themselves have a notion of weeks. 
(Weeks are only secondary units of date measurements (years, months, days 
are the primary ones) and nearly all calendars, all across the globe, use a 
seven-day week.
Weeks are basically the months of the ISO week date 
calendar: https://en.wikipedia.org/wiki/ISO_week_date
I wonder how much of the week-related functionality could be defined by 
just taking a date (in e.g. Calendar.ISO) and converting it into the ISO 
week date calendar. 

~Qqwy/Wiebe-Marten


On Monday, July 10, 2017 at 9:03:53 AM UTC+2, Kip wrote:
>
> With the new capabilities of Calendar in 1.5 I am now adding date and time 
> localisation to a package I maintain (https://hex.pm/packages/ex_cldr).  
>
> CLDR (http://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns) 
> defines a number of symbols to aid formatting and localisation.  Many of 
> these can be supported by the Calendar module (or easily derived).  Some 
> would be better defined in a calendar module - which would imply adding 
> them to the behaviour and to Calendar.ISO.
>
> These functions are:
>
> 1. months_in_year(year) which together with the existing days_in_month/2 
> would allow the calculation of quarters which is relevant in a lot of 
> business contexts
> 2. week_of_year(date) which returns the week number within which the date 
> occurs.  
> 3. week_of_month(date) which returns the week of the month within which 
> the date occurs
> 5. day_of_week_in_month(date) returns the ordinal day (i.e. 2nd in 2nd 
> Wednesday in July)
> 6. year(date) which returns the effective year in which the date lies. 
>  For example in an ISO Week implementation, the "year" may be different to 
> the "year in the date"
>
> Although my immediate focus is date formatting and localisation, these 
> functions are of themselves relevant for other "calendarists" (is that a 
> word?)   Each of these may have quite specific implementation details 
> related to a given calendar and therefore would seem to be appropriate to 
> be part of the behaviour. 
>
> I've tried to think of only those functions which cannot be readily 
> derived without knowledge of the specific calendar but I know this is a 
> slippery slope - especially with anything to do with time and dates.
>
> Thoughts?
>
> --Kip
>
>

-- 
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/4c39d7cf-3bc2-4dc9-b11e-e2221139a080%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7260] [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

2017-07-10 Thread José Valim 
I am OK with delegating more functions to calendar as long as we have use
cases for it. I am also OK with adding a year function but we need to come
up with a better name. :)

Thanks for looking into this Kip!


*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R

On Mon, Jul 10, 2017 at 9:03 AM, Kip  wrote:

> With the new capabilities of Calendar in 1.5 I am now adding date and time
> localisation to a package I maintain (https://hex.pm/packages/ex_cldr).
>
> CLDR (http://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns)
> defines a number of symbols to aid formatting and localisation.  Many of
> these can be supported by the Calendar module (or easily derived).  Some
> would be better defined in a calendar module - which would imply adding
> them to the behaviour and to Calendar.ISO.
>
> These functions are:
>
> 1. months_in_year(year) which together with the existing days_in_month/2
> would allow the calculation of quarters which is relevant in a lot of
> business contexts
> 2. week_of_year(date) which returns the week number within which the date
> occurs.
> 3. week_of_month(date) which returns the week of the month within which
> the date occurs
> 5. day_of_week_in_month(date) returns the ordinal day (i.e. 2nd in 2nd
> Wednesday in July)
> 6. year(date) which returns the effective year in which the date lies.
> For example in an ISO Week implementation, the "year" may be different to
> the "year in the date"
>
> Although my immediate focus is date formatting and localisation, these
> functions are of themselves relevant for other "calendarists" (is that a
> word?)   Each of these may have quite specific implementation details
> related to a given calendar and therefore would seem to be appropriate to
> be part of the behaviour.
>
> I've tried to think of only those functions which cannot be readily
> derived without knowledge of the specific calendar but I know this is a
> slippery slope - especially with anything to do with time and dates.
>
> Thoughts?
>
> --Kip
>
> --
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/elixir-lang-core/20060086-74b8-4a40-bbf4-
> a160783f94d9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFWUU4kfar53n5-jRofS4O8WJmZXfyNrQSp6i3kwuerA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7259] [Proposal] Pipe to any parameter?

2017-07-10 Thread José Valim 
Andrew, "pipe improvements" are common proposals to the mailing list that
are always rejected. Please search for previous discussions on the topic
for more information.



*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R

On Mon, Jul 10, 2017 at 9:01 AM,  wrote:

> Hi guys,
>
> I see a lot of libraries try to allow piping to the first parameter by
> default, but some don't support this easily.
>
> I propose the following syntax to remedy this where it's needed to pipe to
> a specific parameter:
>
> 1) Normal pipe clearly works the same:
>
> %{} |> SomeCode.function(other_params) === SomeCode.function(%{},
> other_params)
>
> 2) The number of > dictates the position of the function we want to pipe
> into:
>
> %{} |>> SomeCode.function("param1") === SomeCode.function("param1", %{})
>
> 3) We could also supply opts and other params:
>
> %{} |>> SomeCode.function("param1", %{opts_are_param_3: true}) ===
> SomeCode.function("param1", %{}, %{opts_are_param_3: true})
>
> 4) We can move to any specific param we want with more arrows, maybe limit
> it to 4, say to avoid it becoming ridiculous.
>
> %{} |>>> SomeCode.function("param1", %{this_is_param_2: true}) ===
> SomeCode.function("param1", %{this_is_param_2: true}, %{})
>
> Thoughts?  Would other people find this useful in some situations?
>
> --
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/elixir-lang-core/2f2e23c7-bbbc-4c20-b177-
> 95dea8628752%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BK-aLAB%2BF8_oWYd9mdSgEDZMCmubdmAMwnAS1pp4%3DZ_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7259] [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

2017-07-10 Thread Kip 
With the new capabilities of Calendar in 1.5 I am now adding date and time 
localisation to a package I maintain (https://hex.pm/packages/ex_cldr).  

CLDR (http://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns) 
defines a number of symbols to aid formatting and localisation.  Many of 
these can be supported by the Calendar module (or easily derived).  Some 
would be better defined in a calendar module - which would imply adding 
them to the behaviour and to Calendar.ISO.

These functions are:

1. months_in_year(year) which together with the existing days_in_month/2 
would allow the calculation of quarters which is relevant in a lot of 
business contexts
2. week_of_year(date) which returns the week number within which the date 
occurs.  
3. week_of_month(date) which returns the week of the month within which the 
date occurs
5. day_of_week_in_month(date) returns the ordinal day (i.e. 2nd in 2nd 
Wednesday in July)
6. year(date) which returns the effective year in which the date lies.  For 
example in an ISO Week implementation, the "year" may be different to the 
"year in the date"

Although my immediate focus is date formatting and localisation, these 
functions are of themselves relevant for other "calendarists" (is that a 
word?)   Each of these may have quite specific implementation details 
related to a given calendar and therefore would seem to be appropriate to 
be part of the behaviour. 

I've tried to think of only those functions which cannot be readily derived 
without knowledge of the specific calendar but I know this is a slippery 
slope - especially with anything to do with time and dates.

Thoughts?

--Kip

-- 
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/20060086-74b8-4a40-bbf4-a160783f94d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7258] [Proposal] Pipe to any parameter?

2017-07-10 Thread andrew 
Hi guys,

I see a lot of libraries try to allow piping to the first parameter by 
default, but some don't support this easily.

I propose the following syntax to remedy this where it's needed to pipe to 
a specific parameter:

1) Normal pipe clearly works the same:

%{} |> SomeCode.function(other_params) === SomeCode.function(%{}, 
other_params)

2) The number of > dictates the position of the function we want to pipe 
into:

%{} |>> SomeCode.function("param1") === SomeCode.function("param1", %{})

3) We could also supply opts and other params:

%{} |>> SomeCode.function("param1", %{opts_are_param_3: true}) === SomeCode.
function("param1", %{}, %{opts_are_param_3: true})

4) We can move to any specific param we want with more arrows, maybe limit 
it to 4, say to avoid it becoming ridiculous.

%{} |>>> SomeCode.function("param1", %{this_is_param_2: true}) === SomeCode.
function("param1", %{this_is_param_2: true}, %{})

Thoughts?  Would other people find this useful in some situations?

-- 
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/2f2e23c7-bbbc-4c20-b177-95dea8628752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.