Re: Immutability RFC
| From: | David Rodrigues | Date: | Wed, 16 Nov 2016 15:37:55 +0000 |
| Subject: | Re: Immutability RFC | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96928@lists.php.net to get a copy of this message | ||
2016-11-16 11:57 GMT-02:00 Silvio Marijić <marijic.silvio@gmail.com>:
> If we treat those objects as values then this should return true. But then
> again there might be some confusion because then two operators are doing
> the same thing. Maybe throw an error ? Suggestions ?
I just thinking about "how it will be done"?
I imagine that we should store all calling to memory, then I see two
problems for this case:
1. High memory consumption: all immutable objects should be stored on
memory eternally (or until the script ends). I mean: if I call it a
hundred times with differents parameters, I'll have a hundred of used
memory, that will avoid any used variables of be GC (once that it
should stores it for references).
2. High CPU consumption: every time that I instantiate an immutable
class, the engine will loop on each possibilities and check if all
parameters match to then return the same object (or then, create a
new). Then the major question for it is: should all parameters of an
immutable constructor be considered on instantiate? Should I pass the
exactly copy (read "reference") of object to the parameter to return
the same instance or a "shallow copy"?
For both problems above, I guess that a "factory pattern with cache"
should works better, once that I could consider the exact value where
it requires to be immutable, and I could cache only if it is really
required, for instance:
class SomeFactory {
private static $cache = [];
public static function getType(Type $type) {
if (!$type->shouldBeCache()) {
// Code flexibility...
return new self($type);
}
if (!array_key_exists($type->id, self::$cache) {
self::$cache[$type->id] = new self($type);
}
return self::$cache[$type->id];
}
}
--
David Rodrigues