PyWart (Terminolgy): "Class"

[Rick Johnson]

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!