Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66948
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "PHP internals" <internals@lists.php.net>, "Rasmus Schultz"
 <rasmus@mindplay.dk>
References: <CADqTB_jjb9v=jZ_RkRucVvY6Vv1EOrqhJEqbcirhVV3ZgpG0vg@mail.gmail.com>
Date: Thu, 04 Apr 2013 19:44:47 +0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.wu0woxzmc9evq2@nikita2206-n56vj>
In-Reply-To: <CADqTB_jjb9v=jZ_RkRucVvY6Vv1EOrqhJEqbcirhVV3ZgpG0vg@mail.gmail.com>
User-Agent: Opera Mail/12.14 (Linux)
Subject: Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
From: inefedor@gmail.com ("Nikita Nefedov")

On Thu, 04 Apr 2013 19:13:54 +0400, Rasmus Schultz <rasmus@mindplay.dk>  
wrote:

> I've been pondering this issue for a while now, and I keep reaching the
> same conclusion, so I'm going to just briefly share what I think.
>
> In my opinion, the real issue is not poor design of the DateTime class -  
> it
> works as you would expect classes and objects to work, in the sense that
> when you make changes (adding, subtracting, changing the timezone) you're
> making changes to the instance.
>
> I can't help but think that the real underlying issue, is the fact that  
> you
> really want value-types and not objects/classes for something like this -
> and we only have a few value-types in php, namely the scalar types (int,
> string, float, bool) and arrays.
>
> If you've ever attempted to build an object-abstraction for other
> value-types, such as colors, URLs (or routes), e-mail addresses, etc. -
> you've faced the same issues: when somebody increases the saturation of  
> an
> RGB color object, do you change the RGB values, or return a new color
> instance? Questions like this stem from the fact that what you really
> wanted for something as self-contained as a color or URL, is not an  
> object,
> but a value-type.
>
> I don't tend to like solutions that solve one isolated problem, when the
> whole class of problems could potentially be address - hearing about
> another DateTime type makes my skin crawl, in particular because it
> introduces all manner of issues with current APIs  that most likely  
> already
> depend on the existing DateTime type. Even coming up with a reasonably
> descriptive (yet practical) name for this class, is difficult - which to  
> me
> indicates a contrived attempt to extend something that only needs to be
> extended for technical (as opposed to functional) reasons.
>
> Please consider addressing the real underlying issue: the need for
> value-types.
>
> Off the top of my head, I'm thinking this could be addressed by  
> introducing
> a new keyword for value-types, interchangeable with "class", for example
> "value".
>
> Value-types would work syntactically like classes and objects. But
> internally they would work like arrays, meaning they are always passed by
> value.
>
> If this could be implemented in such a way that value objects were  
> actually
> internally implemented as arrays, we would get all the benefits of  
> arrays -
> mainly that they would be passed by value, but would not physically be
> copied until modified.
>
> It seems to me, that really is precisely the behavior you want for
> something like a date/time, color, URL, e-mail, etc. - in many frameworks
> and libraries, this behavior is actually emulated, by using arrays to
> represent colors, routes, etc., in order to be able to treat them like
> value-types, but with the enormous downside of having to know which
> value-type is represented by an array, typically relying on static
> helper-methods to modify their properties, and with no chance of any IDE
> support.
>
> Just putting that on the table...
>
> - Rasmus Schultz

Hi,

this is great idea, I thought about it lately.
Though I think it should be called struct like in other other languages.
And it would be very useful if we could declare structs in-place (it's  
useful when dealing with some data-proccessing and all you want is just  
strong-typing but without the need for declaring a whole new class in a  
new file, etc).
But this is a very big feature and I doubt it will get any support :(