"jbrave" wrote:
Well the code you posted is readable, but I really don't understand what you mean, or what the manual means by "this" or "self".
It's really an Object Oriented programming technique. It can make management and control flow easier for some problems, but really it's all a matter of what you're used to and how you think.
In many other languages that support OO programming, a special variable, generally called "this" or "self" is present in methods of an object, and it refers to the current instantiated object. In my previous example, the print method uses the "m" variable to access m.x and m.y. These are the values of the instance of the object. That is, they refer to the associative array entries for that specific object. They are different when called as p1.print() and p2.print(). It's just a convention of the language that "m" refers to the base associative array for the object.
You've seen the point class example above, the classic procedural programming style for that might be something like this:
function point_new(px, py) as object
point = { x:px, y:py }
end function
function point_print(point)
print "Coordinate is "; point.x; ","; point.y; ")"
end function
p1 = point_new(1,2)
point_print(p1)
The benefits of OO programming can be manifold, but so are the drawbacks. I prefer it for many instances because it helps encapsulate all the behavior in a single area, so it's obvious where to look if I want to change or add to how points behave or what they can do. You also don't have to worry about namespace conflicts as much.
Also when you say "function is called as a method on an object" I think that means object.CallFunction() right, like msg.GetIndex() ?
Sort of.
😉 the built-in types are using "interfaces", not methods as they are used in any other respect in the language. Usually it means no difference when coding, but there's specific things you can't do with them (like assign them to variable or as a method on an actual object). Really, all the components and built in types are implemented in C or C++ for speed, and don't interrelate in some ways like purely interpreted code.
It all becomes easier to conceptualize when you've used a language where the sugar on top of objects is a thin veneer at best. E.g. Perl, javascript, brightscript, etc.
-- GandK Labs
Check out Reversi! in the channel store!