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 whole point of creating the object is to pass it around. Just pointlessly copying it out of fear somebody somewhere could modify it doesn't sound the best way. I'd rather just have a clear separation between mutating and non-mutating APIs, and instruct people to use the right ones in right situation - i.e. if you created the object or own it, use mutating ones, if you got object from outside and do not have full ownership of it, use non-mutating ones. > Would that make sense? It’s no different than how our existing value > types like scalars and arrays work. Scalars don't have this problem as, except for string offsets (IMHO not the best idea to have mutable strings too) scalars can not really be changed, just replaced with other scalars. But implementing value objects in PHP is not hard right now - if you don't provide any methods that allow changing state, you've got an immutable object. It's just not always what people using it would want, especially with something as complex as HTTP message. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
