What are modules really for?

[Tito]

Neil Benn wrote:
> Tito wrote:
>> N.Davis wrote:
>>> Functions existing in a module? Surely if "everything is an object" 
>>> (OK thats Java-talk but supposedly Python will eventually follow this 
>>> too) then there should be nothing in a module thats not part of a class.
>>
>> Well, all data in a Python program are objects, in the sense that they 
>> have an identity on their own, and variables are only references to them.
>>
>> Why is it necessary to have all code into classes for meeting the 
>> "everything is an object" panacea?
>>
> If you don't have a class how can you combine functionality with data 
> and hold state - that is one of the points of a class.

Yes, of course. You don't have OO if you cannot define your own classes. 
I only said that I don't find it necessary to have all code confined in 
classes.

> Python has the 
> added concept that if you don;t need this you can create functions with 
> no associations - lots of languages do that but Java, Eiffel, C#, etc 
> don't have that concept.  You need to make a difference between 
> everything is an object and everything is a class here.  A programmer 
> coming from Java/C# wouldn't think about that.
>>
>>> Even a static method is simply a class function that operates on the 
>>> "collection of all instances" rather than a single instance.
>>
>> That is not true. A static method knows nothing about the instances of 
>> a  class, unless you do it your own. Besides, it will work whether you 
>> have created instances of the class or not.
>>
>> So, a static method is just a global method declared withing a class, 
>> which just serves as a namespace for it.
>>
> In java, a static method is the same as a class method in Python, you 
> can then use the cls param to access class attributes (that is what teh 
> OP implied).  However a static method can help with namespacing.  What 
> looks better :
> 
> initialise_local_message_router()
> objPublisher = get_publisher_from_local_router('bob')
> 
> or
> 
> LocalRouter.initialise()
> objPublisher = LocalRouter.getPublisher('bob')
> 
>    IMHO, the second case makes much more sense that a floating function 
> which makes things less expressive.

Yes. So we agree on the fact that the class' name serves as a namespace.

>>> Related classes in the same file? Be careful. Doesn't anything 
>>> "knowing" about anything else compromise encapsulation? Why would 
>>> properly-designed classes have such a close relationship?
>>
>> Question back: why do you think having classes defined in the same 
>> file compromises encapsulation? Classes don't know more about each 
>> other for the fact of being written into the same file. Anyway, in 
>> Python, classes know always too much from each other, don't they?, as 
>> there are no access modifiers for class attributes.
>>
> If I want to change one class and replace the file on the install then I 
> need to put a whole bunch of classes on - increasing the change of 
> making a mistake.

Sorry, I don't understand the previous sentence. What is meant by 
"replace on the install"? And by "to put a whole bunch of classes on"?

> Module scoping exists with globals, also you have the 
> convetnion of creating classes with the name of _XXX to mean module 
> level only.

Do you mean that _XXX server as an access modifier among modules? Yes, 
that can be a reason to split definitions of classes into different modules.

>>> Having back in the day worked on big real-time systems where being 
>>> very strict about encapsulation was a god-send for fighting 
>>> complexity, I feel unnerved by Perl and Python's laid-back OO culture 
>>> of "you can do it if you feel like it but don't have to".
>>>   
>>
>>
>> Well, that is the case with whatever general-purpose programming 
>> language. You have virtually an infinite number of ways to do things, 
>> and most of them are not appropriate.
>>  
>>
> Some languages are more strict than others - yes you need covnentions 
> but you will need more conventions in a less strict language.  The 
> upside is that, if you are careful, you can leverage the added oosness 
> to implement features which would be a pain in other languages.  
> Enterprise systems have different objectives than a cgi script or single 
> client install stuff.  It's a judgement call.
> 
>> The thing with Python is, in my opinion, that it wants to put all the 
>> power in your hands to do whatever you want in the fastest way 
>> possible. If I want to do something, I don't declare a class that 
>> knows how to do it, then create it and invoke the right method, I just 
>> put the code to do what I want to do. If, in between, I find that one 
>> class would make my life easier, I declare it just in place and go on. 
>> If I find repetitive tasks I can declare functions, but I won't go for 
>> a class immediately. Why do you think putting code into functions is 
>> not encapsulating?
>>
>>> While you could do all manner of nasty hacks in C++ I worked with 
>>> people who carefully avoided this.
>>
>> Well done, but messes you can do in whatever language.
>>
> Agreed but in some languages you can cause more havoc than in others, 
> look at the distinction .NET makes between managed and unmanaged code to 
> get a handle on this.

Well, I wasn't talking exactly about making use of dangerous features of 
  languages, but more about the way of using imperative object-oriented 
languages in a non-object-oriented way.

Regards,
Tito