Datum jako služba – dobrý nápad?

Také jsem nad něčím podobným přemýšlel, pokud všude budu vytvářet nový čas, mohou vzniknout nekonzistence (ač to není moc pravděpodobné). Asi bych použil něco jako DateTimeProvider. Problém ale může být s neúmyslnou změnou zvenčí (někdo zapomene clone před modify a je to), protože DateTime není immutable. Takže a) možná spíš factory podle prototypu (vytvořeného při startu aplikace), b) freezable datetime?

Osobně bych do toho HTTP request netahal, např. kvůli CLI.
Maximálně jako implementaci nějakého IDateTimeProvider rozhraní (HttpDateTimeProvider využívající Http\Request a hlavičku, NativeDateTimeProvider využívající new DateTime()).

Majkl578 napsal(a):

Také jsem nad něčím podobným přemýšlel, pokud všude budu vytvářet nový čas, mohou vzniknout nekonzistence (ač to není moc pravděpodobné). Asi bych použil něco jako DateTimeProvider. Problém ale může být s neúmyslnou změnou zvenčí (někdo zapomene clone před modify a je to), protože DateTime není immutable. Takže a) možná spíš factory podle prototypu (vytvořeného při startu aplikace), b) freezable datetime?

Freezable DateTime se mi líbí. I když možná rovnou immutable. Otázka je, jestli by všechny stav měnicí metody měly vracet klon nebo vyhazovat výjimku? Pro jednodušší použití by se mi líbilo, kdyby vracely klon. Pak by se docela pohodlně použila třeba metoda add(). Akorát původní add() vrací DateTime i tak, aby byla fluent, což by mohlo mást. Ale na to by si asi člověk zvyknul.

@Majkl578: Obecně vracet ihned klony se mi moc nelíbí. Přicházím o identitu a tím pádem o ===. Klon by mi mohla vrátit služba v případě změny nebo by mohla mít metodu např. cloneMutable().

Editoval fh (25. 3. 2013 14:55)

@Majkl578: To přejmenování jsem myslel tak, jak jsem ho napsal. BaseControl::getControlPrototype() taky nevrací klon.

Jinak DateTimeImmutable se do PHP 5.5 dostalo, viz https://github.com/….0beta1/NEWS. Uvažovalo se o zrušení, ale nakonec k němu nedošlo, ne?

@fh:

protože to jestli jsou dvě data stejného typu zjišťovat nepotřebuji

K tomu weak comparison neslouží.

Šlo mi o porovnání zda čas je ten aplikační čas.

Opravdu? A nezajímá tě spíš, jestli hodnota je stejná?

Bez identity budu hodnoty data porovnávat složitěji.

Jakto? Objekt není stejný, ale hodnoty ano. Tedy identita neprojde, ale weak comparison ano.

$a = new DateTime();
$b = clone $a;

var_dump($a === $b); // FALSE
var_dump($a == $b); // TRUE

Řekl bych že immutable je v tomto případě lepší než freezable

Souhlasím a vývojáři PHP taky, neshodli se ale na tom, jak to čistě implementovat (kandidát do 5.5 bylo DateTimeImmutable extendující DateTime, což ale nedává smysl a jiná cesta je naopak BC break, proto se to do 5.5 nedostalo).

Podle mě to řešíte moc složitě, já používám toto (jen jako náhradu za volání konstruktoru) a funguje to skvěle:

class Calendar extends \Nette\Object implements ICalendar
{
    /** @return \DateTime */
    public function now()
    {
        return new \DateTime;
    }

    /** return \DateTime */
    public function datetime($time)
    {
        return new \DateTime($time);
    }
}

@Filip Procházka: Můžeš nás zasvětit, znalče? :-)

Aha, myslel jsem, že to odstranili, alespoň se o tom bavili, viz tento thread v php.internals.

Majkl578: Hmm.. Tak to asi zmizi.. Zatim to teda v logu neni. Na zaklade toho mailing listu je otazka jak to implementovat. Aby to tise vracelo klony je teda kvuli LSP asi nevhodne. Asi by to melo hazet v upravovacich metodach vyjimky a mit nejakou tu metodu cloneMutable, co by vratila klasicky DateTime.

@Filip Procházka: Mám to podobně, ale mít to centrálně vyřešené jednou službou mi dává smysl.

Majkl578 napsal(a):
Což ale vůbec neřeší ten základní problém, že skrz systémem nemusí být stejný čas, např. pokud aplikace běží déle než sekundu.

Ok, špatně jsem to pochopil. Tohle řeší jen problém testování kódu ve kterém je new \DateTime().

Mimochodem, jak byste u immutable DateTime řešili metodu getTimezone()? Asi bych to udělal stejně jako DateTime, tedy vracela by immutable objekt DateTimeZone, který by měl metodu cloneMutable(). Názory?

Majkl578 napsal(a):

DateTimeZone je read-only objekt (nejde měnit), takže je to imho celkem jedno.

A jo. Přemýšlím a nezkouším:)