what is a class?

[cxzuk]

I've been working on my own language for a while now, and recently added user-defined units (to help with some of the problems in the language).

E.g. (comments on syntax welcome)
x := 10.1(kg) + 3(g)

is basically sugar for (based on smalltalk syntax)

x := (WEIGHT kg: 10.1) + (WEIGHT g: 3)

where 'WEIGHT' is a class, and 'kg' is a class method taking one argument and returns an object.

this introduces the concept of a 'unit'. A 'kg' is a unit of WEIGHT

I've been analysing and considering what this actually does. Three things have come up that make me question what a class is. NUMBERs, COLOURs and SHAPEs.

I originally constructed a colour as..
RGB red: 255 green: 255 blue: 255
HSL hue: 255 saturation: 255 luminance: 255

But with the unit way of thinking this has combined them into one class called COLOUR. All functionality is equivalent with both ways.

You could also do the same with numbers. An integer is after all in the same 'system' as a real or complex.

So my question is, is INTEGER really a class? or is it just aperspective of a class NUMBER?

What seems to be happening compared to traditonal class usage is the new class has become the traditional abstract class and the new class method constructor has become the traditional class.

look forward to hear thoughts
Mike Brown

[Kevin]

Every INTEGER is a NUMBER, but not every NUMBER is an INTEGER. It's a strict subset. So if you call these things classes, I guess I would call INTEGER a subclass of NUMBER.

[onlyonemac]

Normally though

Every INTEGER is a NUMBER, but not every NUMBER is an INTEGER. It's a strict subset. So if you call these things classes, I guess I would call INTEGER a subclass of NUMBER.

Normally though we make "integer" a base type rather than a class.

[gerryg400]

Normally though

Every INTEGER is a NUMBER, but not every NUMBER is an INTEGER. It's a strict subset. So if you call these things classes, I guess I would call INTEGER a subclass of NUMBER.

Normally though we make "integer" a base type rather than a class.

You mean we make NUMBER a base type? INTEGER is derived from NUMBER.

[onlyonemac]

Normally though

Every INTEGER is a NUMBER, but not every NUMBER is an INTEGER. It's a strict subset. So if you call these things classes, I guess I would call INTEGER a subclass of NUMBER.

Normally though we make "integer" a base type rather than a class.

You mean we make NUMBER a base type? INTEGER is derived from NUMBER.

No, we make integer a base type. Conceptually, an integer is a type of number just as a float is a type of number, and a long int is a type of integer just as a short int or a char is a type of integer - consequently, the compiler allows casting from one "number" type to another (sometimes with a loss of precision), but the base type is still "integer" (or more accurately, "long int", "short int", "char", etc.).

[cxzuk]

Every INTEGER is a NUMBER, but not every NUMBER is an INTEGER. It's a strict subset. So if you call these things classes, I guess I would call INTEGER a subclass of NUMBER.

Yes, subset! That makes sense.

What I've created above is a superset, its a sum of all subsets. This makes me question inheritance, perhaps typical inheritance is upside down? What i think i want is to extend the superclass with each subclass definition (like a partial class with a label), this would mean an instance of NUMBER would contain all the code from class INTEGER.

This would mean the code provided by "INTEGER" is a specialization provided by NUMBER, and can be used in situations where its constraints can be proven?

Mike

[cxzuk]

A pseudo code example,

Code: Select all

class SHAPE {
  point POINTS[];

  area() {
    // Calculate the area of any polygon.
    result = 0;
    foreach(c = 0; c < POINTS.length - 1; c++) {
      result += POINTS[c].x * POINTS[c+1].y
      result += POINTS[c].y * POINTS[c+1].x
    }
    result += POINTS[POINTS.length].x * POINTS[0].y
    result += POINTS[POINTS.length].y * POINTS[0].x
    result = result / 2
    return result;
  }
};

extend SHAPE with RECTANGLE {
    int width, height;
    // We can use "specialized" variables to speed up computation (bit like an index/cache)
   // We still need to update POINTS in the superclass.

    area() {
      return width * height;
    }

   // ... A list of constraints? If we can prove its a "rectangle" we can use these methods
   // If constraints are broken, decomposes to a SHAPE.
   // If its ALWAYS a rectangle, we can code eliminate and remove unnecessary "SHAPE" code.
}

[gerryg400]

No, we make integer a base type. Conceptually, an integer is a type of number just as a float is a type of number, and a long int is a type of integer just as a short int or a char is a type of integer - consequently, the compiler allows casting from one "number" type to another (sometimes with a loss of precision), but the base type is still "integer" (or more accurately, "long int", "short int", "char", etc.).

Oh, I can now see how you got confused an made an incorrect statement.

[zdz]

The better question is "what is an object?".

[kzinti]

Classes are not types, but categories of types. What C++, Java, C# and similar languages call a "class" is actually a "type". This is very unfortunate. Functional languages like Haskell tends to get it right.

You can see this inconsistency in C++ when you use 'typename' when declaring template parameters. Also in both C/C++ you have the "typedef" keyword.

onlyonemac nailed it when he said:

Conceptually, an integer is a type of number just as a float is a type of number.

So 'number' is the class. 'integer' and 'float' are types. 'number' is not a base type, it is a class.

[kzinti]

So my question is, is INTEGER really a class? or is it just aperspective of a class NUMBER?

"Integer" is a type of class "number". That's what the language theory nomenclature says.

[Boris]

The sole reason some languages see Integers/Reals are different classes is because they are handled not in the same way in the CPU.
Here is one big difference that makes people using integers instead of reals in financial apps:
+ Integers can overflow. This can be fixed with checks in code.
+ Reals ( float/ double) can underflow

[cxzuk]

So my question is, is INTEGER really a class? or is it just aperspective of a class NUMBER?

"Integer" is a type of class "number". That's what the language theory nomenclature says.

I think you're right, and also agree with the mismatch of classes and types. I've been avoiding types in my language but I suspect I need to understand there place soon.

After sleeping on this problem, the reason I want to extend the SHAPE class with the RECTANGLE class is because SHAPE must have all the methods RECTANGLE provides. Another way to achieve this is to have subclasses only be able to redefine methods, and not extend its inherited classes.

This feels right at first glance, and inheritance becomes 'specialisation' rather than extention. (multiple inheritance would provide overriding the intersection of methods of two or classes), Data members are encapsulated in my language so "caching" or.helper variables would be allowed.

Time to read up why inheritance allows extending of its superclass

[cxzuk]

The better question is "what is an object?".

my definition of object in my language is;

A fully independent computational unit that can ONLY receive and send messages with other objects. State AND behaviour are encapsulated. (This is the actor computational model).

An object is the atomic unit of construction of a program. (Objects are not Russian dolls, you can't crack an object open and more objects fall out. The better metaphor is routers connected together in a network passing messages to each other).

Objects can however be 'simulated' (virtualised) but providing a virtual environment.

An object has a network interface - A driver to access the data received (A traditional example is a calling convention and stack details) - And a "Controller" (mvc), logic to understand what the message means (A 'view' is state in a stateful protocol. The controller uses the view information to help understand messages) and invokes model methods once it understands the message intentions.

And object has a default Controller (with a stateless protocol so no view).

I'm pretty happy with the object side of things but comments always welcome

[kzinti]

This feels right at first glance, and inheritance becomes 'specialisation' rather than extention.

Using class (as in C++ class) inheritance for extension is bad design. It should always be about specialization. In C++, avoid subclassing as much as possible as it is the highest form of coupling.

Note that using abstract class in C++ to define interfaces is perfectly fine. But these have nothing to do with subclassing. You can see that in other languages like C# where you use the "interface" keyword instead of abusing the "class" or "type" keywords.