Hi Rowan and folks, > While this is an intriguing idea, it only solves a narrow set of use cases. > For instance: > - The class might want different behaviour for different operations; e.g. > Money(42, 'USD') + Money(42, 'USD') should give Money(84, 'USD'); but > Money(42, 'USD') * Money(42, 'USD') should be an error. > - Properties might need to interact with each other; e.g. Distance(2, > 'metres') + Distance(2, 'feet') could result in Distance(2.6096, 'metres'); > but if you calculate one property at a time, you'll end up with Distance(4, > 'metres'), which is clearly wrong. > The fundamental problem is that it ignores the OOP concept of encapsulation: > how an object stores its internal state should not define its behaviour. > Instead, the object should be able to directly define behaviour for the > operations it supports.
Thank you for pointing it out. Given what Tim and you mentioned, trying to make BCMath\Number have more than just "a value" is probably the wrong approach. (Except for some properties for rationality of calculation) Inheritable classes are attractive, but there are too many problems to solve to make them a reality, some of which are probably impossible to solve. I explored various possibilities, but in the end, I think making it a final readonly class is the healthiest option. To you all: The discussions thus far have been reflected in the RFC. I would be very happy if you could check it out. (Thanks Tim, the <PHP> tag is very easy to read.) https://wiki.php.net/rfc/support_object_type_in_bcmath Regards. Saki
