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. 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.
>
>
>>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. Module scoping exists with globals, also you have the
convetnion of creating classes with the name of _XXX to mean module
level only.
>
>
>>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.
>Regards,
>Tito
>
>
Cheers,
Neil
--
Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany
Tel : +49 (0)351 4173 154
e-mail : [EMAIL PROTECTED]
Cenix Website : http://www.cenix-bioscience.com
--
http://mail.python.org/mailman/listinfo/python-list
