-----------------------------------

Dragon20942

Mon Jun 08, 2015 9:43 pm


Class vs. Module vs. Type

-----------------------------------

So from what I understand, type is like a struct in C++. You can store a bunch of different non-function fields in a type using "record", so when you make a variable of that type, each field in the variable is like a subvariable that you can conjure up with variable_name.value

Modules are similar to this, except you can store function fields as well. You can choose what fields are accessed outside of a module using "export".

Classes are modules, but with the added bonus of inheritance.

This is the basic idea that I have. Is that all? I feel like modules are fairly strange because you can use type and global functions, or simply a class to really do everything in a module, the way I understand it. What unique functionality does a module contribute? Are they only useful to cleanly pack up code that isn't quite complex enough to necessitate a class? Are there keywords that respond only to modules? Please help clean this up :p
Oh yes, and there's "collection" as well... Oh man...


-----------------------------------

Dreadnought

Mon Jun 08, 2015 11:46 pm


Re: Class vs. Module vs. Type

-----------------------------------

Personally I would say that Turing's var a :
    record
        x : int
        y : int
    end record
a.x := 1
a.y := 2
put a.x + a.y

Notice that there is no "name" for the type of a, in fact here the type is unique to a (try defining a new variable separately in the same way and trying to assign the value of a to it).
Furthermore, type Matrix : array 1..2, 1..2 of int
type PointerToInt : ^int 

Modules are not types, nor are they objects (at best they are singleton objects and I still say that's pushing it) and they aren't intended to function as records with functions (we have classes for that). Modules are more so intended to allow you to divide your code up into pieces (using Are there keywords that respond only to modules?
As far as I know classes respond to all keywords that modules respond to. Modules can be implemented as a class with a single instance that is created when the program starts and exists until it exits. My guess is that Turing actually implements them this way (note: this is only my guess). 

What about collections?
Collections are a mysterious bunch. I'm not sure why they are declared with [tdoc]var[/tdoc] since the "variable" is not considered a variable by Turing.  My two theories for the weird use of [tdoc]var[/tdoc] are that it's done, either to prevent it from being a regular type (in which case you could create variables of that type), or to allow members of the collection to contain pointers to members of the collection ("var" might prevent Turing from complaining that the collection isn't defined yet).  Ignoring that, I think the best way to view collections (if you know C or C++) is as a struct whose instances can only be manipulated by pointers. This is in contrast to [tdoc]record[/tdoc] which can only be manipulated by the actual instances.

Hopefully that helps clear things up. Sorry for the wall of text.


-----------------------------------

Zren

Tue Jun 09, 2015 5:11 am


Re: Class vs. Module vs. Type

-----------------------------------

Turing, 

Not so.


type Vector2D :
    record
	x : real
	y : real
    end record

fcn newVector2D (x, y : real) : Vector2D
    var v : Vector2D
    v.x := x
    v.y := y
    result v
end newVector2D

type Particle :
    record
	pos : Vector2D
	vel : Vector2D
	visible : boolean
	c : int
    end record

proc initParticle (var p : Particle)
    p.pos := newVector2D (maxx / 2, maxy / 2)
    var angle := Rand.Real () * Math.PI * 2
    p.vel := newVector2D (cos (angle) * Rand.Real (), sin (angle) * Rand.Real ())
    p.visible := true
    p.c := Rand.Int (0, maxcolor)
end initParticle


Classes have syntatual sugar to call their methods boxInstance->move(x,y) as if there was a function like Box_move(boxInstance, x, y) and where the first parameter (boxInstance) is magically hidden and you can access it as [tdoc]self[/tdoc].


-----------------------------------

Dreadnought

Tue Jun 09, 2015 8:23 am


Re: Class vs. Module vs. Type

-----------------------------------


Turing, 

Not so.


type Vector2D :
    record
	x : real
	y : real
    end record

...
I guess my explanation wasn't very clear. Zren is right you can use [tdoc]type[/tdoc] to bind a recordType to a name. My point was that [tdoc]record[/tdoc] creates the recordType but does not bind it to a name. You must use [tdoc]type[/tdoc] to bind the type to a name and without [tdoc]type[/tdoc] you would be out of luck.

Sorry for any confusion.