Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <54CDF420.1030801@garfieldtech.com>
Date: Sun, 01 Feb 2015 03:38:40 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEbg-4YrBumSmCmvTbgVQTS=U2dm3gLzO6im69qQp6brxm=RMg@mail.gmail.com> <54CBC804.7050706@gmail.com> <54CD7668.30301@garfieldtech.com> <54CD7975.8040908@gmail.com> <54CDE9FF.40700@googlemail.com>
In-Reply-To: <54CDE9FF.40700@googlemail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Immutable variables and objects
From: larry@garfieldtech.com (Larry Garfield)

On 02/01/2015 02:55 AM, Crypto Compress wrote:
>
>>> The with*() methods in PSR-7 are documented to return a new instance,
>>> not modify the existing instance.  Yes, there's no way in PHP itself to
>>> force that syntactically, which is why documentation exists. :-)
>>>
>>> Also, in the benchmarks we've run the performance cost of all those new
>>> objects is measured in nanoseconds, ie, small enough that we're not
>>> worried about it.  (Hats off to the PHP Internals folks for making that
>>> fast!)
>> It is great that this is fast, but I wonder (maybe off-topic?) why do
>> it? I.e. it is clear that in something like:
>>
>> $a = new Request->withHeaders(...)->withBody(...)
>> ->withEncoding(...)->withETag(...)
>>
>> the intermediate objects are useless and nobody needs 5 new objects when
>> you do it. Am I missing something here?
>
> Hi,
>
> my assumptions after some testing:
> - This is only true in case of reassigning ($a = clone $a) the old 
> variable, as refcount for underlying values remains 1 for all values 
> in clones, so cow don't need to copy anything.
> - If the old object is not thrown away, then memory consumption is 
> doubled and the "fast" argument is wrong.
> (Performance, of cloning an object without copying values and of some 
> method calls, is negligible.)

I'm not sure that anyone has benchmarked the memory impact of the 
immutable approach yet.  I will pass that along and see what data comes out.

> Omit mutator methods (with*/set*) is a simple and logical way to 
> achieve immutability in PHP. No need for const/final/...

(Someone feel free to declare this thread off topic now, as we're 
basically just rehashing discussions had weeks ago on the FIG list.)

The original calls for immutable HTTP message objects had no with*() 
methods.  They objects were set from their constructor and that was the 
end of it.  However, many people (myself included) pointed out that such 
objects, in actual practice, would be completely unusable.  Middlewares 
need to be able to pass information from one layer to another; the most 
straightforward way to do that is (as Symfony does and PSR-7 recommends) 
an attributes collection on the request.  But if you can't set that 
without going through a new constructor manually it becomes horribly 
difficult to do. Similarly, middlewares that want to set cache 
information for a whole application, encrypt/decrypt headers, or do 
anything else actually useful have to manually replicate the object 
themselves.

An object with a complex constructor with lots of parameters offers, 
really, no value over a big-ass array.  It's almost worse in my 
experience.  (And yes, I've used such APIs and yes, I detest them.)

Too, the constructor is obviously not part of the interface, which means 
every implementation would have its own constructor, thus eliminating 
the benefit of having a standard at all.

The with*() methods solved that problem entirely, and enabled a nice 
fluent style for those who are into such things.

--Larry Garfield