Hi Rowan > As I replied to Jordan, I don't see why this is connected to "scalar" vs > "object" types at all. An object - particularly an immutable one - is just a > way of declaring a type, and some syntax for operations on that type. There's > really no difference at all between these: > > $half = $whole / 2; > $half = numeric_div($whole, 2); > $half = $whole->div(2); > > In PHP, right now, the last one is only available on objects, but there have > been proposals in the past to change that; it's just syntax. > > For rounding, the first one is the real problem, because there's nowhere to > put an extra operand. That problem is the same for a class with an overloaded > "/" operator, and a "scalar" type which has a definition of "/" in the engine. > > Maybe it feels more obvious that an object can carry extra state in private > properties, but internal types don't actually need private properties at all. > PHP's "array" type has a bunch of different state without being an object (a > linked list of items, a hashtable for random access, an iteration pointer, > etc); and SimpleXMLElement and DOMNode are exposed in PHP as separate > classes, but actually store state in the same C struct provided by libxml2. > > So I see it just as an API design decision: do we specify the rounding mode > of numeric division a) on every operation; b) on every value; c) in a runtime > setting (ini_set); d) in a lexically scoped setting (declare)? > > My vote is for (a), maybe with (d) as a fallback.
There is no difference in how the data is held. Agree. What I'm referring to is how to initialize the value. If the user has to specify some parameters, or can specify them as options, that is already the behavior of the object. I'm making these opinions from an API design perspective. How the data is held internally is irrelevant. zval has a lot of data other than values. What I want to say is that if multiple types of parameters are required for initialization, they may only serve as a substitute for object for the user. Regards. Saki
