On Mon, Jan 31, 2011 at 5:52 AM, Roberto Cavada <cav...@fbk.eu> wrote: > On 01/30/2011 11:53 PM, Robert Park wrote: >> [...] but now that the other classes are in other files, >> the module _itself_ is providing the same encapsulation that the class >> was giving me, and is thus redundant. > > In this perspective, you are using classes as mere namespaces of your > functions and variables. As I said, if you do not exploit hierarchies and > relations (and you don't as you have no inheritance and no polymorphism) > there is very little difference between module and class levels (IMO there > are some disadvantages with modules, see below).
Right, I'm not using any inheritance for the main app class, no. What kind of things would I want to inherit from that would be useful to my application? I just literally have no idea what I could inherit from there. I do use inheritance in a small way with my Photograph class, but that's very minor. >> My point with that example was not that the second version was better, >> but that they were so similar that it proves that the module itself is >> "good enough" and that I don't actually benefit from having this >> particular class inside a module. > > If you don't see advantages with classes, let's stay with benefits of having > only modules. Do you see any that are not syntactic like number of dots > between IDs and 'self' appearing as first formal param? Now, I did say that I'm not arguing against classes in general, only that one specific class. And no, I started this thread solely because I was searching for syntactical simplification for my application. >>> Indeed if your application code fits into a thousand of LOC, you can >>> choose whatever style you like, either having everything pushed into one >>> module or split into classes/packages/modules, no really matters. >> >> Ok, but I am not arguing against all classes, just the class that >> represents the graphical interface that the user interacts with. > > Then I guess your GUI is necessarily very small. I cannot imagine a large > GUI all fitted into a module, and even within one single class. How do you > separate the GUI logics and the presentation layers? Can you split the GUI > into (interconnected, still decoupled) pieces? ( someone calls them > components.) If you have components, you can reuse/factorize code in > different parts of a single application, or you can rearrange the GUI for > another application. I don't totally follow you here. In "app.py" I have a single class with many methods. Some methods provide the actual application logic, and some methods are just boring signal handlers for various tedious GUI activities. However, I do import other classes that represent specific things (photo files, XML files, etc), and use them in sensible ways. >> Can you explain how module-globals make code less portable? Is there a >> platform on which Python doesn't support module globals? I'm genuinely >> curious. > > Mmm, 'portability' was a bad term I chose, as it can create > misunderstandings I am sorry about that. I probably had to talk about > 'reuse'. Extending my objections, what if you wanted to have: > - threads involved I did try threads once and found it was quite terrifying, but that was WITH the class definition, not module globals! > - unittests of some parts I have a large test suite and I don't really see how this would make any difference. The testsuite calls "app.some_method()" and the syntax is the same whether "app" is an instance of a class, or a whole module. > If you have poor locality of your code, you'll get into troubles. Using > module-level variables does not help with locality. Ok, that is a good point and that is pretty much the major problem that I ran into when i tried (and failed) to actually do the class methods -> module globals conversion that I've been talking about. Thanks for your responses everybody, this has given me a lot to think about and I think I'm learning. ;-) -- http://exolucere.ca _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
