On 20 juil, 07:17, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Sat, 19 Jul 2008 13:13:40 -0700, nicolas.pourcelot wrote: > > On 18 juil, 17:52, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > >> On Fri, 18 Jul 2008 07:39:38 -0700, nicolas.pourcelot wrote: > >> > So, I use something like this in 'sheet.objects.__setattr__(self, > >> > name, value)': > >> > if type(value) == Polygon: > >> > for edge in value.edges: > >> > if edge is_in sheet.objects.__dict__.itervalues(): > >> > object.__setattr__(self, self.__new_name(), edge) > > >> > Ok, I suppose it's confused, but it's difficult to sum up. ;-) > > >> You are setting attributes with computed names? How do you access them? > >> Always with `gettattr()` or via the `__dict__`? If the answer is yes, why > >> don't you put the objects the into a dictionary instead of the extra > >> redirection of an objects `__dict__`? > > > Yes, I may subclass dict, and change its __getitem__ and __setitem__ > > methods, instead of changing objets __setattr__ and __getattr__... But > > I prefer > >>>> sheet.objects.A = Point(0, 0) > > than > >>>> sheet.objects["A"] = Point(0, 0) > > But with computed names isn't the difference more like > > setattr(sheet.objects, name, Point(0, 0)) > vs. > sheet.objects[name] = Point(0, 0) > > and > > getattr(sheet.objects, name) > vs. > sheet.objects[name] > > Or do you really have ``sheet.objects.A`` in your code, in the hope that > an attribute named 'A' exists? > > >> Oh and the `type()` test smells like you are implementing polymorphism > >> in a way that should be replaced by OOP techniques. > > > I wrote 'type' here by mistake, but I used 'isinstance' in my code. ;-) > > Doesn't change the "code smell". OOP approach would be a method on the > geometric objects that know what to do instead of a type test to decide > what to do with each type of geometric object. > > Ciao, > Marc 'BlackJack' Rintsch
Thank you for your advises, it's very interesting to have an external point of view. No, I have not anything like 'sheet.objects.A' in the library code, but I use then the library in different programs where things like sheet.objects.A sometimes occur. However, since it is not so frequent, I may indeed subclass dict, and change __getitem__, __setitem__ and __delitem__, and then redirect __getattr__, __setattr__, __delattr__ to previous methods... This would not break library external API, and it may speed-up a little internal stuff. I'm not very expert in OOP ; imho it's largely a mean and not a goal. On one hand, 'a method on the geometric objects that know what to do' would require them to contain some code concerning the object manager... I don't like that very much. On the other hand, object manager should not rely on object's implementation... I will think about that. Thank you all of you for your answers. I'm sorry I may not have time to reply further, it was interesting :-) (even if it's a bit difficult for me to write clearly in english ;-)) -- http://mail.python.org/mailman/listinfo/python-list