On 3 February 2015 06:59:06 GMT, Alexander Lisachenko
wrote:
>I want to add a link here to the Java article about Value Types, this
>information is quite interesting:
>http://cr.openjdk.java.net/~jrose/values/values-0.html
>
>Probably, immutable value objects will be soon in Java world according
I want to add a link here to the Java article about Value Types, this
information is quite interesting:
http://cr.openjdk.java.net/~jrose/values/values-0.html
Probably, immutable value objects will be soon in Java world according to
this information:
> Conclusion
>
> Along with the questions, we
Lester Caine wrote on 02/02/2015 09:19:
This is probably because I still don't understand objects, as I still
just consider them as arrays with a few more complex elements. I STILL
work on the basis that is I pass by reference, I can make modifications
to the data while if I don't I get a copy an
On 02/02/15 07:31, Alexander Lisachenko wrote:
> Agree in that point with you, this can be a good instrument if implemented
> in PHP. I see a good point in it by using this with interfaces and "const"
> modifier for parameters:
>
> class Foo {
> public function bar(const Baz $object); // Requi
Hello, internals!
2015-02-01 4:01 GMT+03:00 Andrea Faulds :
> I think having some means to create value type classes (i.e. PHP 4-style
> classes) would be beneficial. These classes would have the same always-copy
> or copy-on-write behaviour that PHP’s scalar types and arrays have. They’d
> be pe
On 01/02/2015 01:01, Andrea Faulds wrote:
Given that PHP is dynamic, not compiled, and function calls can have side
effects, though, this would be difficult to enforce. You’d need to check that
all calls made within the function do not have any side effects on that value…
I’m not sure how work
On 01/02/2015 01:06, Andrea Faulds wrote:
the intermediate objects are useless and nobody needs 5 new objects when
>you do it. Am I missing something here?
I assume the reason for doing this is so you can’t ever modify the object from
a distance, you must always create a new one to avoid messin
On 01/02/15 09:38, Larry Garfield wrote:
> (Someone feel free to declare this thread off topic now, as we're
> basically just rehashing discussions had weeks ago on the FIG list.)
Just as HHVM is not PHP neither is FIG ... so any discussion on ether
list is not relevant here since many people will
Hi Larry,
Il 01/02/15 10:38, Larry Garfield ha scritto:
On 02/01/2015 02:55 AM, Crypto Compress wrote:
- 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,
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 pe
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 measu
On 01/31/2015 06:55 PM, Stanislav Malyshev wrote:
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 nob
Hi,
> On 1 Feb 2015, at 02:09, Stanislav Malyshev wrote:
>
>> Here, there’s no redundant objects made, but if you pass $a on, it’d
>> be automatically copied by PHP, so you don’t need to worry about it
>> being modified.
>
> I don't think it's a particularly good solution in this case, as in ma
Hi!
> Here, there’s no redundant objects made, but if you pass $a on, it’d
> be automatically copied by PHP, so you don’t need to worry about it
> being modified.
I don't think it's a particularly good solution in this case, as in many
cases (especially DI setups, many design patterns, etc.) the
Hi Stas,
> On 1 Feb 2015, at 00:55, Stanislav Malyshev 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,
Hey Larry,
> On 1 Feb 2015, at 00:42, Larry Garfield wrote:
>
> Immutability, generally, offers two advantages:
>
> 1) It makes it easier for humans to reason about code.
>
> 2) It makes it easier for compilers/runtimes to reason about code.
>
> For the former, good programming practices/stan
Hi!
> 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
> ob
On 01/30/2015 12:05 PM, Rowan Collins wrote:
On 30/01/2015 13:07, Alexander Lisachenko wrote:
What is wrong here? Emulated immutability. All methods will create a
separate instance of request, so
$baseRequest->withUri()->withMethod()->withHeader()->withBody() will
create
total 5 object instance
Hi!
> What I want to discuss is true immutability flag for variables and
> parameters. There are a lot of languages that use "final" or "const"
> keywords to prevent modification of variables. We can use this approach by
> extending language syntax as following:
Most of the languages that use "fi
On 30/01/2015 13:07, Alexander Lisachenko wrote:
What is wrong here? Emulated immutability. All methods will create a
separate instance of request, so
$baseRequest->withUri()->withMethod()->withHeader()->withBody() will create
total 5 object instances. It's a memory overhead and time consumption
2015-01-30 18:07 GMT+03:00 Andrea Faulds :
> This approach wouldn’t solve the problem you’re describing. You *still*
> need to produce a new request object, because the request object is
> immutable. The mutability of its *properties* isn’t the issue.
Thank you for this answer. However, pay an
Hi Alexander,
> On 30 Jan 2015, at 13:07, Alexander Lisachenko
> wrote:
>
> Hello, internals!
>
> Today I was looking at PSR-7 and discovered this part of code:
>
> $body = new StringStream(json_encode(['tasks' => [
>'Code',
>'Coffee',
> ]]));;
> $request = $baseRequest
>->withUri
22 matches
Mail list logo
