i would bundle them into one... but would probably split on another level. adding items to a user may well be "posessions"... so it depends. That might well be a model of User with related stuff, which is mapped to database in another way (one2many or Relator object/m2m or whatever), and is shown in UI in yet another way.
or, using your examples, str.to_int is same as int.from_str and can be implemented anywhere in _one_ place - and reachable from whereever, but they belong to another concept: conversion. So if it goes extremely OO, it would be convertor.str( something). pythonwise the convertor is the default namespace - so u get len(), int(), str() etc various protocols. And anyway, all these "Dogmas" are just ways to do it. None matches reality in_principle. One has to match the complexity of the _model_ with the complexity and importance of the task/concept. As long as you're consistent, use whatever u like / is suited better - but always think of someone else reading it after one year (it can well be you but in quite diff.mindset). ciao svilen www.svilendobrev.com On Monday 13 April 2009 17:59:46 Nebur wrote: > A good question. I think we agree that both ways can work well... > Usually, I do prefer the "less OO" style. In your example, a pure > mapping class and business logic in a user manager. > > The main reason is that what you call "OO style" seems to enforce a > lot of arbitrary decisions. > For example, when you bind an EMail object instance to a User > object instance. > Where to put the addXXX() method - into the User, or into the EMail > ? (I see that ugly question appear repeatedly, e.g. in the language > design. Do we want str.to_int() or Str.from_int() or int.to_str() > ... etc...) > Also notice that the "OO style" is not necessarily a pythonic style > (which may also be desirable). > Let's look out for examples: > Python design prefers even to use a global len() function instead > of str.len() etc. (hm, I don't like especially that case, but I > think GvR also may have had its good considerations.) Or consider > sqlalchemy-ORM where most functionality is in the orm-session. > Other orms (SqlObject etc.) prefer to put methods into the mapped > classes (i.e."Active Records"). > The sqlalchemy design may also have other reasons (e.g.unit-of-work > is wanted). But indepently from collecting actions in a > unit-of-work, the design with methods in the session -not in the > objects- feels well. (Sadly, this is more gut feeling than > rational.) > > I think these design question is fundamental, and a lot of gurus > already have written about OO for decades now. Should there really > be no guru article, and no forum discussion about that ?? I'd also > appreciate anyone showing me what knowledge already exists here. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
