Class vs. Module vs. Type
| Author |
Message |
Dragon20942
|
 Posted: Mon Jun 08, 2015 9:43 pm Post subject: 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... |
|
|
|
|
 |
Sponsor
Sponsor
|
|
|
Dreadnought
|
| Posted: Mon Jun 08, 2015 11:46 pm Post subject: Re: Class vs. Module vs. Type |
|
|
Personally I would say that Turing's type is similar to C++'s typedef. They allow you to create aliases for existing types. Perhaps the confusion here stems from the fact that, in Turing, record does not allow you to bind the type created to a name, unlike struct[/tdoc]. For example consider the following Turing code
| Turing: | 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 really does behave like [url=http://www.cplusplus.com/doc/tutorial/other_data_types/]typedef as you can see below
| Turing: | 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 unit to give each piece its own file) that are independent of the code that imports them. For example the functions Draw.Box[tdoc] and [tdoc]Draw.Oval are both part of the Draw module, Music.Play and Music.PlayFile are in the Music module. However you don't need to import these modules since Turing does so automatically. Gui on the other hand is a module that is not imported by default, hence why you must always import it. If you want to see the actual definitions for these modules they can be found under \Support\Predefs\ and \Support\lib\ in your Turing installation.
I like to think to think of classes as more powerful records. Classes, like records, allow you to bundle various pieces of data together but also allow you to define functions that can operate on these bundles. We often try to make these bundles resemble real objects and as such like to refer to them as objects. You can get more structure through inheritance to create objects that share certain attributes. For example, the GUI module has a very generic widget class, called GenericWidgetClass, which has functions like Show, Hide, Dispose, SetPosition, etc. and a more specialised class, called GenericButtonClass, that has the functions ConsiderButtongDown, ConsiderKeystroke, etc. (this is a bit simplified, there are actually a few levels of inheritance between the two classes).
So why do we need modules?
Well, in principle you might write some code that does something somewhat generic like creating a Graphical User Interface (I'm sorry that the GUI keeps being used as an example, but its the best example that is included in Turing). You want to allow other people to use your code in their programs. One solution is to give people all the code for them to copy-paste into their program, but this is messy and error-prone (what if you both use the same variable names?). Putting the code in a separate file having them use include solves the first problem, but not the second. By wrapping everything in a module that sits in a separate file you fix both. Notice that here you really want a module, not a class. This is not some object, this is not something you want to have multiple instances of. This is a collection (not a Turing collection) of functions, types, variables, etc. that, together, are useful for some focused purpose.
Now suppose you were Microsoft, you create an operating system and would like to allow people to do things like get input from the keyboard. But you're worried that someone might try to be malicious and read from the keyboard when they are not allowed to (perhaps to steal some passwords). So you don't want people to see everything that is happening in your keyboard module. You need certain parts of your module to have access to things that you might not want users to tamper with. This is where export comes in, allowing you to control what is visible from the outside. Now in Turing this doesn't really accomplish much since the user will have your code anyway. But in C++, you can compile modules (well... the equivalent sort of thing) and provide this compiled file along with a (header) file that lists what is "exported" for the user to use.
Dragon20942 wrote: 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 var since the "variable" is not considered a variable by Turing. My two theories for the weird use of var 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 record which can only be manipulated by the actual instances.
Hopefully that helps clear things up. Sorry for the wall of text. |
|
|
|
|
|
Zren
|
| Posted: Tue Jun 09, 2015 5:11 am Post subject: Re: Class vs. Module vs. Type |
|
|
Dreadnought @ Mon Jun 08, 2015 11:46 pm wrote: Turing, record does not allow you to bind the type created to a name, unlike struct.
Not so.
| Turing: |
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 self. |
|
|
|
|
|
Dreadnought
|
| Posted: Tue Jun 09, 2015 8:23 am Post subject: Re: Class vs. Module vs. Type |
|
|
Zren wrote:
Dreadnought @ Mon Jun 08, 2015 11:46 pm wrote: Turing, record does not allow you to bind the type created to a name, unlike struct.
Not so.
| Turing: |
type Vector2D :
record
x : real
y : real
end record
... |
I guess my explanation wasn't very clear. Zren is right you can use type to bind a recordType to a name. My point was that record creates the recordType but does not bind it to a name. You must use type to bind the type to a name and without type you would be out of luck.
Sorry for any confusion. |
|
|
|
|
|
|
|
Register
Wiki
Blog
Search
Turing
Chat Room
Members
