A touch of class

You can do an amazing amount of good with VrPython without knowing anything about Object Oriented Programming (OOP). For that matter most, or at least many things you can do without even knowing much about Python. In my opinion though, knowing more is always better than knowing less. Let's talk a little about how I understand OOP working out in Vr. To begin with there is a very good explanation of the basic concepts on Wikipedia. I could make up my own example of the biggies like class, object, inheritance but they do such a good job there that I'll just trust anyone who needs a basic understanding to read it (3-5 minutes tops).
Let's look at a line. In VrPython there is a class called PyVrLine. Any object which is created from that class has many attributes, characteristics, data (whatever you want to call it) which describes it's state. Examples of these attributes (the word I'll stick with) are it's layer, graphic pointer, width, coordinate list and so on. A line also has many methods, or functions it can perform based primarily on it's current state. When ever I create an individual object or instance of that class, I have access to all the attributes and methods that go with it. In Vr the individual object is created with the command
Line=PyVrLine()
I have often wondered if I am confusing things by using the word "Line" as the name of the particular object. Sure it is descriptive and relevant, but for example purposes it needs to be clear that I could use any name for the object being created which is of the class PyVrLine. It is just an identifier of the unique entity I'll be using just like Dennis is just a name used to identify this particular object of the Human class.
In any case, whatever we call a particular instance, once we have a PyVrLine(), the fun can begin. On of the most useful functions when starting off is Id(). Once there is a PyVrLine object, Id() will use the function built into it to bring up a familiar set of identification menu keys and wait for the user to click button #1. If the click meets all the criteria to find a line Id() will not only return the line number of the line it found, but will populate the PyVrLine object with all the attributes of the identified entity. It does the exact same thing as Load() but allows for visual identification in the current workspace. Once the PyVrLine object is loaded (or I suppose created from scratch with default values) the whole host of methods that can get, set, or compute information based on the current state become available.
The key is that a Vr object can't just be looked at even as a complex collection of data, but also as the family of functions that allow user interaction with it. This frees the developers to grant access to the power of the internal magic in a secure manner, and the user from having to understand what is going on (or having to re-invent the wheel for typical data interaction).
Ok I'm rambling and really need to bring this to a close. Besides the fact that OOP is really cool, and it helps to have a simple understanding of how it works out in Vr, what is the point? Is there any reason that a person might want to learn to use classes in everyday programming? I very rarely do, and most of the true object oriented modules I've written were done because I wanted to give it a try, but here is an example. I have a module which contains an angle class. An object created from this class of course stores the value of the angle it represents, but it also contains methods that allow it to represent itself in radians, degree-minutes-seconds, decimal degrees, bearings with quadrant, any of the above in varying text formats along with an overloaded repr(). Along with this there are methods that allow for conversion between the varying systems. All these things are easy enough to do on the fly, but a consistent interface and descriptive names make programs that use the class easier to read, and playing with basics like this makes understanding modules written by really intelligent programmers a bit easier to follow.