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).
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?
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.
have a handful of classes that represent various kinds of data that my
application uses, and that makes great sense because each class can be
instantiated multiple times and each instance represents something
meaningful.
Typically the top-level logics, controller and presentation of the
GUI is instantiated only once, but this does not mean that it is not
meaningful. Again, classes are not supposed to be instantiated
multiple times.
However, if your application is intended to grow up, if you need
contracts (interfaces) to agree with other programmers, if you need to
Ok, but how does having module top-level functions instead of class
instance methods (for a class that can only be instantiated once) make
any difference?
In principle no, in practice it largely helps. I think it is trivial
to say that the introduction of OOP did not change the software, as
you can do whatever with a procedural-paradigm, as well as you can
do OOP with a non-OOP language. OOPs is only for reducing
(hopefully) costs of software.
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
- unittests of some parts
- code generated by metaclasses at compile time
- refactoring needs, e.g. you want to move your code (or part of it)
in a different possibly larger place.
If you have poor locality of your code, you'll get into troubles.
Using module-level variables does not help with locality.
My two cents,
r.
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
