Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66953
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_i20MPuF=1rg0S+m8dPBwpmEWu_AwhaS1=c1KUQkvOHuw@mail.gmail.com>
References: <CADqTB_jjb9v=jZ_RkRucVvY6Vv1EOrqhJEqbcirhVV3ZgpG0vg@mail.gmail.com>
	<op.wu0woxzmc9evq2@nikita2206-n56vj>
	<CADqTB_i20MPuF=1rg0S+m8dPBwpmEWu_AwhaS1=c1KUQkvOHuw@mail.gmail.com>
Date: Thu, 4 Apr 2013 20:03:24 +0300
Message-ID: <CAGbiJu9XktS0JD=yDiy_bPYFnAoGfYyPVYXo0WNwHBXY7mKpPw@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b33cde8db9ff504d98bf284
Subject: Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
From: dor.tchizik@gmail.com (Madara Uchiha)

--047d7b33cde8db9ff504d98bf284
Content-Type: text/plain; charset=ISO-8859-1

OOP is not a beginner's concept. I don't want to sacrifice good coding
practices for a better learning curve.

Also, a glance on the manual would reveal that the method returns the same
instance for chaining (which is also debatable, why do we even do that?)
On Apr 4, 2013 7:46 PM, "Rasmus Schultz" <rasmus@mindplay.dk> wrote:

> Is it a really big feature if it's just syntactic sugar and internally
> stored as an array? say:
>
> struct Color
> {
>     public $r = 1.0;
>     public $g = 1.0;
>     public $b = 1.0;
> }
>
> Stored internally this might be something like:
>
> array('__type'=>'Color', 'r'=>1.0, 'g'=>1.0, 'b'=>1.0)
>
> Have you worked extensively with DateTime or other value-as-object types?
>
> $today = new DateTime();
> $yesterday = $today->modify('-1 day');
>
> echo "today: " . $today->format('Y-m-d') . "\n";
> echo "yesterday: " . $yesterday->format('Y-m-d');
>
> Code like this is a major mind-boggle to most programmers - it's not by any
> means obvious from reading this code that $yesterday and $today are in fact
> references to the same object, and the output of this script is the same
> date, twice.
>
> Most programmers automatically think of "atomic" things like date/time and
> color as being values, and it's easy (even for experienced developers) to
> make mistakes. In my own code, for example, constructors that take DateTime
> instances as arguments usually have to safeguard by doing something like
> this:
>
> public function __construct(DateTime $begin, DateTime $end)
> {
>     $this->begin = clone $begin;
>     $this->end = clone $end;
> }
>
> This makes redundant copies of objects in every instance, which isn't
> optimal - but enables code like this to actually do what you expect:
>
> $date = new DateTime();
> $week = array();
> for ($i=0; $i<7; $i++) {
>     $week[] = new Day($date);
>     $date->add('P1D');
> }
>
> if the Day constructor doesn't clone $date, you have problems - that's what
> started the debate about a new DateTime type in the first place, I think?
>
> existing DateTime is fine, if what you want is a timestamp you can
> manipulate for reasons *other* than using the resulting value, e.g. for
> printing out successive dates - as soon as you want to do something other
> than using the immediate value contained in the object, trouble's
> a-brewin'.
>
> a new DateTime-type would solve that by having the add() and sub() methods
> clone internally - but I can already do that by extending DateTime myself
> (as countless frameworks and libraries have done) with all the same
> problems in terms of API issues and expected behavior. (in cases where you
> do expect the internal value to change.)
>
> as said, it only addresses the problem for DateTime, which is just one
> isolated example of natural value-types represented as dysfunctional
> objects.
>
> why not address the real issue, which is the lack of value-types?
>
> other languages have them for the same reasons.
>
> had we had value-types at the time, no one would have thought to implement
> DateTime as an object...
>

--047d7b33cde8db9ff504d98bf284--