I have believed for a very long time that "class" was a poor choice of keyword
to designate an "object definition".
Firstly, the word /class/ does not transform smoothly into CS from English. NO
English definition of "class" comes anywhere close to describing the
"structured source code that defines an object". Or even generally as:
"something that defines something else". You could try to hammer
"classification" into the round hole, but you soon find out it's just a damn
square peg!
Secondly, "class" is confusing to newbies. How can someone understand the
fundamentals of OOP (which defines objects and interfaces) when they are asked
to write classes? (teacher:) "Okay /class/, we are going to create a new
object by writing a class." (student:) HUH?
Thirdly, once people *DO* understand that a "class" is simply an "object
definition", they still go on to say idiotic things like: "Classes are
objects"! It is obvious these people are a victim of their own terminology.
============================================================
Other possible terms include:
============================================================
"subclass":
Since every "user defined object" *must* subclass /something/, using this
word would infer such a relationship to the reader. HOWEVER, we would then need
to differentiate the general usage of "subclass" (as in: an object that is an
extension of another object) from a "user defined subclass" (as in: source
code). In any event, "subclass" is a good contender. He's going to the 12th
round for sure.
"template":
This term is very close, but still lacking a concrete relationship between
source code (definition of object) and the resulting "thing" living in memory
(object). I think this one is TKO in round 3.
"object":
This is my favorite word however it does suffer a "verbial" disconnection.
What are we suggesting? A single word can be very ambiguous as to intent.
However, if we couple the word "object" with the word "define" we then inject
intent. "define object" on it's face is perfect! We know everything we need to
know. 1) We are defining "something" and 2) that *THAT* "something" is an
object! YAY!
Now since "methods" and "functions" (PyWart on these terms coming soon!)
require defining, the syntax will now be symmetrical (omitting for now that
funcs/meths only use "def"!). However we could drop the "def" and use only
"object" to save a few keystrokes and a lot of pyparsing.
I am sure the main arguments against such a clear and logical syntax would be
that we would confuse "object definitions" with "real live objects" in normal
conversation. But i say that is non-sense because we NEED to be more specific
when conversing anyway. Choosing a word like "class" just because we don't want
to use two words to refer to "source code that defines an object" (in
conversation) is ridiculous. This syntax will inject specificity into our
communications and convey meaning more appropriately.
Dear language designers: Stop propagating such foolish terminology! End the
infection of "class" in all source code, docs, and daily conversation. Be more
consistent and logical. Resist temptation to use poor terminology simply
because other languages have done so before you. Grow a pair already!
--
http://mail.python.org/mailman/listinfo/python-list
