People tend to desire API changes that go on the same directions they are going.
That's nature... Daniel Ribeiro Gomes Pereira Twitter <https://twitter.com/#!/drgomesp> | Facebook<https://www.facebook.com/profile.php?id=100000407054469> | LinkedIn <http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39> iPhone: +55 (48) 9111-0931 2012/12/11 Stas Malyshev <smalys...@sugarcrm.com> > Hi! > > > As Nikita says, from an ORM perspective, an object is always immutable > > (at least with current implementations I know of), and that's because > > they can simply use the object hashes to identify two different objects. > > Why for ORM Date is even an object? In most databases, date is a basic > value type, and should be accepted by value, not as a complex object. > So, it should also be identified as the value - for number 1, you do not > need additional identity or hash except it being number 1, same should > be for dates. > > > I don't believe (at all) in "if you don't need it mutable, don't use > > modify() oroverride modify()". If the API is there, people will use it. > > We tried to implement an immutable DateTime in userland, but it doesn't > > work out well... > > Why it doesn't work well and why PHP needs to be changed because of it? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
