Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66957
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGbiJu9XktS0JD=yDiy_bPYFnAoGfYyPVYXo0WNwHBXY7mKpPw@mail.gmail.com>
References: <CADqTB_jjb9v=jZ_RkRucVvY6Vv1EOrqhJEqbcirhVV3ZgpG0vg@mail.gmail.com>
 <op.wu0woxzmc9evq2@nikita2206-n56vj> <CADqTB_i20MPuF=1rg0S+m8dPBwpmEWu_AwhaS1=c1KUQkvOHuw@mail.gmail.com>
 <CAGbiJu9XktS0JD=yDiy_bPYFnAoGfYyPVYXo0WNwHBXY7mKpPw@mail.gmail.com>
Date: Thu, 4 Apr 2013 19:58:52 +0200
Message-ID: <CAMyk_AaG5Fu5DjKc9oKPGy_a8qK6RNcqeyQK=86K2vm6XK+3bQ@mail.gmail.com>
To: Madara Uchiha <dor.tchizik@gmail.com>
Cc: Rasmus Schultz <rasmus@mindplay.dk>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044786b55ffd2c04d98cba86
Subject: Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
From: linepogl@gmail.com (Lazare Inepologlou)

--f46d044786b55ffd2c04d98cba86
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/4/4 Madara Uchiha <dor.tchizik@gmail.com>

> OOP is not a beginner's concept. I don't want to sacrifice good coding
> practices for a better learning curve.
>
>
This is interesting. Best practices from other languages, including C#,
Scala etc, have shown that some things are better represented by value
types. Even in PHP, strings are value types, because it is better this
way...

Besides, having to think whether to use a value type or a reference type
does not make anything easier to learn! Value types is an advanced,
post-OOP concept, not targeted to beginners anyway.




> Also, a glance on the manual would reveal that the method returns the sam=
e
> 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 =3D 1.0;
> >     public $g =3D 1.0;
> >     public $b =3D 1.0;
> > }
> >
> > Stored internally this might be something like:
> >
> > array('__type'=3D>'Color', 'r'=3D>1.0, 'g'=3D>1.0, 'b'=3D>1.0)
> >
> > Have you worked extensively with DateTime or other value-as-object type=
s?
> >
> > $today =3D new DateTime();
> > $yesterday =3D $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 sam=
e
> > 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 lik=
e
> > this:
> >
> > public function __construct(DateTime $begin, DateTime $end)
> > {
> >     $this->begin =3D clone $begin;
> >     $this->end =3D 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 =3D new DateTime();
> > $week =3D array();
> > for ($i=3D0; $i<7; $i++) {
> >     $week[] =3D 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 thin=
k?
> >
> > 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 oth=
er
> > 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 myse=
lf
> > (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...
> >
>

Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel

--f46d044786b55ffd2c04d98cba86--