Talk:Class (computer programming)/Archive 1

HTML/XML/JavaScript

Discussion of how HTML and XML classes (such as for CSS markup) are similar or different might be interesting. They also have the notion of attributes and instantiation; an analog for "methods" might be JavaScript functions which operate on particular markup blocks. -- Beland (talk) 18:53, 12 October 2008 (UTC)

Classes, as traditionally seen in computer science, are a specialization of the common definition of class. The class attribute in HTML is based off that common definition, not the specialized one here. --Maian (talk) 06:39, 13 October 2008 (UTC)

Introduction - cohesive and layer?

I was responsible for the reorganization of this article several months ago (I was Special:Contributions/72.177.38.5 and Special:Contributions/72.177.62.3). The following two statements in the intro were originally there:

a class is a cohesive package that consists of a particular kind of metadata

a class is the most specific type of an object in relation to a specific layer

I'm not familiar with those concepts, and they were only mentioned in the intro without being detailed in the rest of the article, so I considered removing them. But I left them as they were, moving the statements around in the intro to try to make them fit as well as they could.

So now, I'm wondering if anyone who knows about these two concepts can elaborate on them, or at the very least, inform us if they are relevant to the article.

--Maian (talk) 20:04, 9 November 2008 (UTC)

Class methods

Maian said "class methods aren't an integral part of the class concept, so removing that from the 1st paragraph." But in my opinion, object creation is not an integral part of the class concept either. Many process classes, such as the Math class, are used without creating any objects. In terms of an object, a class is indeed a blueprint for that object. But on the other hand, this is not the Wikipedia article about objects, it's about classes. The concept of a class was originally used in Simula to refer to not only the object, but also it's actions. See [1]. Therefore, it is correct to say that a class is a blueprint for an object. But a class is so much more: all actions of the machine are defined by classes; where no object is present, actions can still be performed, e.g. the Math class. I think that what is missing is a distinction between "process class" and "object class", where this article seems to introduce only the "object class" and sidelines the "process class" as a non-integral part of the class concept.

This problem is: an object is created by a class. A class is thus a blueprint for an object. But not all classes are blueprints for objects. Therefore, I think that this page on class can use some tweaking. Twocs (talk) 16:35, 20 June 2009 (UTC)

Not all languages have the concept of "class methods" or "static methods". For example, Scala, another JVM language (since you're apparently coming from a Java standpoint), doesn't have static methods in the same vein as Java. Why? Because if you consider that the class itself is an object, than its "class methods" can be thought of as either instance methods of the metaclass that created that class, e.g. methods of a MathClass class that creates the Math class object, or as object-specific methods (not sure what the correct terminology is here) on the Math object itself. --Maian (talk) 18:51, 7 July 2009 (UTC)

Examples section is bloated and inconsistent

The examples section for this article is large and very inconsistent. There are typically two formats for example sections for programming articles: 1) an example or two in pseudo-code; and 2) examples for a variety of languages. This article uses the latter format. The main reason for there to be multiple examples across each language is for readers to compare and contrast between the syntax each language provides. However, if the examples are so inconsistent, it's hard for the reader to draw any conclusions.

So, I suggest standardizing on set of features that most OOP languages can support (or emulate): methods, static vs. instance, single inheritance, public vs. private. Any deviations from that set should be explicitly explained in comments.

--Maian (talk) 06:20, 12 December 2008 (UTC)

Reasons for using classes - contains weseal words and unverifiable statements in support of OOP

This section contains weasel words, phrases, unsupported statements and a clearly cherry-picked example

• 'solid work' - weasel
• 'programming is generally much easier...' - POV, unverifiable
• 'Classes can accelerate development...' - unsupported, unverifiable
• 'it is typically the case that using or extending the well-tested class will reduce the number of bugs - as compared to the use of freshly-developed or ad hoc code - in the final output'

this statement would be likely be true for most extensions to ANY well tested code in ANY paradigm so what is the point in stating it other than to convince us that OOP is superior to earlier paradigm?

The particular example given (a GUI drawing subroutine for a window), could be consdidered to be 'cherry picked' merely to promote the subject of OPP without imparting verifiable information.

multiple calls

• '...can't be acheived in imperative program paradigms without 'repeatedly' calling a user interface?'

Where is the evidence for this statement? Asyncronous processes existed long before OOP that could operate semi-autonomously with changed parameters via a list or control block setting using a single call. If multiple calls to an interface were previously required to draw a window, the interface is obviously badly designed in the first place and nothing whatsoever to do with the emergence of OOP and classes as suggested.

intuitiveness

• '...it is more intuitive to represent the window as an object and tell it to draw itself as necessary'

There is nothing at all intuitive about windows 'drawing themselves' - in fact it could be considered a miracle if this was really what occured!ken (talk) 12:37, 15 October 2009 (UTC)