On Mon, Apr 2, 2012 at 11:45 AM, Gustavo Lopes wrote:
> In sum, I don't think it hurts much and it helps the extension stay
> consistent.
It can hurt in the sense that the procedural is ugly in this case and
nobody sane will ever use it. Introducing useless new functions do not
sound like a good
On Mon, 02 Apr 2012 11:44:17 +0200, Derick Rethans wrote:
On Mon, 2 Apr 2012, Johannes Schlüter wrote:
Basically it is good to have those calender stuff available. I wonder
how this relates to our datelib. Can this somehow be integrated, at
least for Gregorian calender times, so one can easily
On Mon, 02 Apr 2012 11:13:02 +0200, Pierre Joye
wrote:
The only thing I really dislike is the procedural API. The prefix
"intlcal_" is not very nice, but what I really doubt is the usefulness
of the procedural APIs for the Calendar resources. It makes little to
no sense to have it as it bring
On Mon, 2 Apr 2012, Johannes Schlüter wrote:
> On Mon, 2012-04-02 at 10:35 +0200, Gustavo Lopes wrote:
> >
> > I have exposed ICU's Calendar API to PHP via the intl extension. It
> > allows date calculations with Gregorian, Chinese, Coptic, Ethiopic,
> > Hebrew, Indian, Islamic (civil/religious
On Mon, 2012-04-02 at 10:35 +0200, Gustavo Lopes wrote:
> Hi
>
> I have exposed ICU's Calendar API to PHP via the intl extension. It allows
> date calculations with Gregorian, Chinese, Coptic, Ethiopic, Hebrew,
> Indian, Islamic (civil/religious), Japanese, Persian, Taiwan and Thai
> Buddhis
hi Gustavo,
Very nice job :)
The only thing I really dislike is the procedural API. The prefix
"intlcal_" is not very nice, but what I really doubt is the usefulness
of the procedural APIs for the Calendar resources. It makes little to
no sense to have it as it brings nothing in comparison to the
