No Thoughts about Everything

[Christopher A. Craig]

b-blochl <bblochl2 at compuserve.de> writes:

> My  starting point was the modifier static in combination with final. (I will
> use it to define natural constants once, without a chance to change them, may
> be eventually by inattention.) But I argue that that JAVA-concepts are not
> familiar in the python world. (One should look over the fence from time to
> time!) The modifier "final" (he keyword final) means that the value assigned
> to a name is final and will never change. such name declared *static and
> final* will exist as a single copy of the constant and will be shared among
> all the objects instantiated from the class. In JAVA a variable (or class) is
> set static simply by applying the modifier "static" and a variable (or class)
> is set final simply by applying the modifier "final".(To remember:
> "1. Beautiful is better than ugly." and "3.  Simple is better than complex.") 
> Then one copy of that variable (object) will be created the first time that a
> class is loaded, and that copy will remain in existence until the program
> stops running. (That ist possible in python by the builtin
> "staticmethod(function):". But I find the application of the keyword static
> more elegant and simple.

The purpose of those modifiers is not to prevent programmers from
changing them but to provide the compiler with information on
optimizations.  There is no real benefit from declaring something
final rather than establishing a convention that things that are upper
case are constants and should not be changed, and the addition of a
useless keyword makes the language more complex by definition.

If you can't trust your fellow programmers to follow style guidelines,
how can you trust them not to remove final from the declaration?

> *Again: The essential point of my interest was  to combine static with final
> in python as well!* That is state of the art and common use in real OOP. That
> is not a pervert idea of mine but a weel established concept. I never saw my
> snipplet of dirty code as the philosophers stone. ( The philosophers stone is
> sometimes very similar with the fools stone.) I know the unacceptable
> disadvantage of the error message if someone tries to change the value of the
> tuple. So it is not applicable in a real program! I used it to clearify my
> imagination of the realisation of "static final". So obviously that everyone
> thinks me to write crazy code and wearing a too large hat or pushing beginners
> off the programmers wagon! And I never ever planned to "teach" such nonsense
> code to everyone. (Again it was only a try to clarify the proposed
> concept.)

It is common in C-like languages because of their heavy weight
optimizer, it's not at all common in SmallTalk or OCmal (the former of
which I would be hard pressed not to call "real OOP" if Java is).
That said, Python doesn't claim to be any other language.  In Python
all data protection is by convention (which I'll note I've never seen
a problem with in practice).

> Preventing  programmers to reassign values of Variables is obligate suspicion
> for the sake of robust professional program development. The essential point
> is, that no one should ever finger a static final varable in strict OOP and
> there very often is absolutely no need for! It is absolute wrong to speak of
> ill-intentioned /undisciplined programmers. Mankind is very unperfekt and one
> should stay on earth. Every programmer always is ill-intentioned
> /undisciplined - at first I myself! As a fact the largest error in computer
> science is sitting in front of the computer! ( May be the wife/husband of a
> programmer may have left him, or actually the beer drinking event
> "Oktoberfest" in Munich makes some headache. And so on.)  So it should be a
> rule of the trade to make the making of errors impossible where ever
> possible. For instance use of "static final" will help. Use it when ever
> appropriate!

Here is where you part ways with most Python developers.  I'm not sure
what your first sentence means, but the context is pretty clear.  Yes,
programmers are imperfect, but they are hopefully at least capable of
reasoning.  If I establish a coding style that you are not to change
the value of uppercase variable, I would hope anyone over the age of 5
understands that to mean you are not to change the value of uppercase
variables.  Similarly, roads could be constructed to constrain you to
one side of the street, but we expect adults to understand and abide
by convention.  

If someone changes a value I meant to be constant then they have done
one of two things.  

1) they imported my module and changed stuff within either my module
or an instance of my class without bothering to read the
documentation.  I don't see how declaring the variable final would
have helped this.  They could just as easily have called my add()
function expecting it to subtract, which no amount of language
handholding would fix.  If you can't be troubled to read and follow
the API, you shouldn't expect to get good results.

2) They modified my module without bothering to read it.  In this case
they could just as easily removed the "final" statement from my
variable declaration.


> There are some different fields of application - for some fields
> python is perfect as it is. But I miss some modern concepts in
> python I would like to find and use. I do miss the usual concepts of
> modern programming techniques in python. For instance I find it
> practically impossible to map a UML design to a python program. I
> would say *UML sets the conceptual standard for todays professional
> application programming*. Conceptual standard says nothing about
> syntax. My vision and dream is the marriage of the scripting power
> with the intentation syntax with the strict object power of
> JAVA.. (I am awaiting a flame?)  And I have pointed out that sefety
> *must be* mostly part of the language to keep systems save and
> manageable!  In the Jython index I found no entry for the keyword
> "final".

There was a time when people would have used the same arguments to say
that C was not following the path of modern languages like Cobol and
would surely go the way of the dinosaur in short order.

-- 
Christopher A. Craig <list-python at ccraig.org>
"I wouldn't be surprised if the architecture of Intel's microprocessors
were eventually linked to the eventual fall of mankind." Steve Gibson