Am 21.03.2011 um 08:33 schrieb Christophe Pettus: > I'd like to make one more pitch for a slightly different implementation here. > My concern with CompositeField isn't based on the fact that it doesn't map > one-to-one with a field in the table; it's that it doesn't have any of the > semantics that are associated with a field. In particular, it can't be: > > - Assigned to. > - Iterated over. > - Or even have a value.
You would be able to use composite fields normally (as in "normal django field"): >>> foo = Foo.objects.create(coords=(0, 0)) >>> foo.coords (0, 0) >>> foo.coords = (4, 2) >>> foo.coords.x # == foo.x == foo.coords[0] 4 Sidenote:: Subclassing the default implementation of composite field values should be easy: >>> type(foo.coords) <type 'Vector'> >>> foo.coords.length 4.4721359549995796 >>> foo.coords += foo.velocity __ Johannes -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
