gws / php-valueobjects Goto Github PK

Packagist is using https://packagist.org/packages/gwis/php-valueobjects
Github is using https://github.com/gws/php-valueobjects

The issue comes when I want to use my fork whilst waiting for a PR merge.

My composer has { "type": "vcs", "url": "https://github.com/rquadling/php-valueobjects" }, in the repositories, but the package name doesn't exist in both places.

I either have to say I want gwis/php-valueobjects when I am using Packagist (and therefore no fork) or gws/php-valueobjects when I am using Github (and therefore ONLY my fork which I'll delete once you've merged my PR).

Ideally they should be the same name.

Can this be resolved please?

Hi.

Wanting to use DateTimeImmutable for DateRange, but the typehint is current DateTime.

Moving to DateTimeInterface would be ideal, but this is PHP5.5+ only.

Polyfilling of the DateTimeInterface and DateTimeImmutable is all possible, but the issue is that you cannot add the DateTimeInterface to DateTime so you would lose compatibility at some stage.

Maybe a branch for PHP5.5+ that uses DateTimeInterface typehint, rather than DateTime would be nice.

For some reason, our production server wasn't built using --enable-bcmath. As a consequence we have to use --ignore-platform-reqs to get this package installed.

Is there any benefit in any of the following ideas:

1. Split php-valueobjects into more specific types.
2. Make any currently required extension a suggested extension and use extension sniffing to allow the class to be used (Money.php is currently the only user).

Having said that:

1. will still fail on production if locally bcmath is available, but fails at composer install stage.
2. will still fail on production if locally bcmath is available, but fails at runtime if the Money VO is used.

I suppose just getting the admin to install bcmath is the solution.

Unless you have any other ideas.

Currently, to test a DateRange (or DateTimeRange) to see if it is anchored in the PAST/FUTURE or both (INFINITE), you have to create a new DateTime(DateRange::PAST) or DateTime(DateTimeRange::PAST).

#7 allows you to simply test your existing range (date or datetime).

$dr1 = new DateRange(new DateTime('2006-09-06'), new DateTime('2006-09-15'));
$dr1->isPast(); // false

Hi.

Really minor thing, but could you retag/release the lastest changes please?

Thank you.

Whilst DateRange seems to concentrate on dates only (i.e. no implicit setting of times to 00:00:00/23:59:59), http://en.wikipedia.org/wiki/ISO_8601#Time_intervals says that the format includes the time part.

I've created #3 to address this.