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
--
http://mail.python.org/mailman/listinfo/python-list
