On Thu, Jul 30, 2009 at 10:14 AM, Laurens Van Houtven <l...@laurensvh.be>wrote:
> Oh, by the way: would you guys expect NMEASentences to be immutable > objects? > Yes, but by convention, not necessarily by enforcement. The really important thing is that the framework should not share or mutate NMEASentence objects internally. > I suppose it makes sense, but maybe I've been thinking too much > Haskell recently. After all, an NMEASentence is an alternative way of > describing a past event (namely, something that a GPS told you). > Changing it would be like changing history, you can't do that -- even > if you're really replacing it with the same data but encoded > differently. > > I know that you can't *really* make immutable python objects, but > they'd be immutable in the sense that: > > sentence.latitude, sentence.longitude = Coordinate(50.49), > Coordinate(-3.34) > > ... wouldn't work (specifically, latitude and longitude aren't really > attributes of the class, but things you can get with my __getattr__ -- > and I don't set __setattr__, so you'd need to know the guts of the > class, which currently are public but I might make private before the > code review). > Ugh. __getattr__, really? Is that necessary? It would be nice not to rely on this kind of magic. For NMEASentence, I don't really care, because I hope I'm never going to write an application that actually deals with one of those. But if you have a Point object or something like that, then I think it's important to have a return-a-modified-copy API if mutation is actually disallowed. For example, point.moveTo(50.49, -3.34) => a new Point.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
