OOP Assignment

CS 396

OOPs World: a basic OOP interpreter

Rules: Individual Effort, no collaboration

DUE DATES:

Intemediate deliverable: Part 1: Tuesday 4/9, by class time
Final Deliverable: Tuesday 4/16, in class

You will note the final deliverable is due directly after spring break. I've made the first checkpoint due the Tuesday before Spring Break, so you'll have time to ask questions about the second half before you go. Actually the second half is really pretty easy, once you have your head around it. My point: we all know darn well you aren't going to work "as much as you'd planned" over Spring Break, so this is really set up to allow you to get it done before you leave!

Overview:

This is probably the coolest programming assignment ever imagined. When you finish it, you will have (a) a solid understanding of OOP language concepts and behavior and (b) an incredible sense of power and knowledge. It isn't everyday that you write your own private language!

More specifically, you will implement a simple interpreted object-oriented programming system. The system will read in a data file containing "class definitions" (sort of equivalent to "compiling" in Java). The format for these definitions is given in detail below; you may assume that given definitions are syntactically correct (although I did build some basic sanity-checking into my implementation out of habit). After the definitions are loaded, the system will allow the user to interactively instantiate defined classes, and manipulate the resulting objects. Your system will provide graceful error-handling, class fields and methods, self-reference (i.e., the Java "this" keyword) and other standard features of OOP environments.

Objectives:

An in-depth understanding of what exactly objects really are --- what core functionalities create the "object-ness" of a language.
A functional understanding of how objects actually do what they do and, in particular, what aspects of that behavior might incur certain computational costs.
A better understanding of scoping and control of naming environments. Your solutions will have to carefully structure the intra-object environments to properly deal with reference to fields, method parameters, shadowing of fields/method params be each other or by local variables, and dealing with overloaded method names.

Assignment:

Your assignment is to implement an interpreted object-oriented programming environment. By "interpreted" I mean that, rather than compiling your source files (containing the class definitions), the user simply loads the class definitions into the interpreter environment. This "defines" the classes. The user may then instantiate classes to her heart's content and, of course, pass messages to the resulting instances.

The class definitions

Class definitions are stored in a text file. Of course, the file may have Scheme comments embedded in it as well (the built-in "read" method ignores these). The general format for class definitions is as follows:

(class <class-name> (parent: <parent>) (constructor_args: <constructor_args>) 

	(ivars: (name1 val1) (name2 val2)...(namen valn))

	(methods: 

		(<meth-name> (<args>) (<body>) )

		(<meth-name> (<args>) (<body>) )

		<etc>

	))

This definition format is quite straightforward; syntactic conventions are of course lisp-like. Details:

Note that the val1...valn values used to initialized the instance variables (aka. ivars) could be literals, e.g. (foo 3), or computed values, e.g. (foo (+ 3 4)), which would result in an initial value of 7 for ivar foo. In short, you have to "eval" the provided values during initialization.
Note that the computed values may reference constructor args, e.g., (fum (+ 4 my_arg)) where my_arg is a constructor arg passed in. Formally speaking, the constructor args are "in the scope of" the ivar initializations.

Here are a couple of sample class definitions (one plain one, one that shows inheritance at work) that illustrate the most important aspects of class functionality. Note that, in the definition above, a provision is made for specifying a "parent" class. For Part I of the assignment, this is just a placeholder; in PartII of the assignment, you'll implement the inheritance feature.

PART I : The core OOP system.

The main part of this assignment consists of creating the core OOP system, which knows how to read in class definition files, define the new classes, and then allows the user to instantiate and play with simply objects.

Your program should provide several important top-level functions:

(load-classes "filename") ---> loads the class definitions contained in the file called "filename". As in the sample file given above, a single file could contain many class definitions. Your LOAD function should cause these definitions to be loaded and "compiled" (processed), resulting in the definition of the new classes in the environment. Load-classes should print out the names of each class as it's loaded, i.e., something like "loaded class: the-class-name". This is just so that we can see that it's doing its job and know what classes were loaded. Hint: Here is a simple load-file function that you can use as a starting point.

(new <class-type> <args>) --> The new function takes in the name of a previously defined class, along with whatever constructor args it requires, and creates a new instance of the class.

After you create new objects you should, of course, allow passing of messages to them. So the general plan would be:

> (define obj1 (new myClass arg1 arg2)) ;; Use the loaded classdef to create a new instance of myClass

> (obj1 'method_name <method args>) ;; Invoking the new instance of the object using a method and its args.

Here is a more concrete sample sequence I produced loading the two sample classes given earlier.

Self-testing BONUS: Here is a little "script" in Scheme that loads a given code file, then runs some tests. It's set up to load and test the two test class definition files CLASS1.TXT and inherit.txt that I gave you earlier. This little script is very very similar to what my testing program will do in testing your code. Just put all your files in the same directory and run it: it should load your program, load the test classes, and run some tests. Here is the output it produces. This is an EXCELLENT way to self-test your solution so that you know it's ready!

Some details:

Your system must implement the self-referential capability seen in most OOP systems. Specifically, you should support a special *this* variable that essentially points to the current instance, i.e., the object in which the reference to *this* is appearing. Thus, a method invocation of (*this* 'foo 4 5) invokes the method "foo" defined in the currently instance with the args 4 and 5.
So can one pass in functions as arguments to constructors or to methods? Of course! The beauty of scheme is that fns are just like all other data --- you can pass them around, return them, no prob. And because our objects are essentially just functions (procedure objects), we can easily pass instances of certain classes (objects!) in as parameters. Check out this example test class file and the corresponding screenshot of it in action.
NOTE: I've tossed a functon defn into the class file here, just for my convenience --- not strictly spec (you won't be expected to handle such function defs in class files) --- you can either modify your load-classes to deal with it (two lines), or just grab it outta there and define it in your main code file.

Intermediate deliverable for Part 1:

Turn in a 1-2 page sheet showing your basic object system loading and working on:

my basic sample test file
a basic test class you yourself have created

Your printout should show you loading the class file, creating a few objects, and passing them some messages to set and display object ivars. Submit this printout of your interaction window, plus a printout of your class definition file. A printout of your code is NOT required.

Turn this in as a hardcopy printout on the date specified (see top of page).

PART II : Inheritance

As we discussed in lecture, inheritance is one of the most thorny, complex issues that must be dealt with in implementing an OOP system --- although, at the same time, inheritance functionality is also a central feature of the OOP paradigm. If you examine the research literature in OOP, you will find that dozens of experimental languages have been designed to explore variations of different inheritance models --- with much heated argumentation of pros and cons of each. In brief, the decisions made in designing the inheritance model for a language affect nearly every aspect of the language ranging from security of information-hiding, complexity, reliability, performance, and difficulty of implementation.

Implementing fully-functional inheritance is non-trivial. Fortunately, I am asking only for a basic inheritance mechanism. Still, it requires some thought and gaining a deep understanding of what inheritance really means. The goal is for you, in implementing even this rudimentary mechanism, to gain some insight into the challenges associated with design and implementation of an inheritance mechanism.

IMPORTANT! It is very worth your while to think about how you'll add inheritance BEFORE you finalize your approach to coding Part I of the assignment. In other words, your implementation of Part I should be made with inheritance support in mind --- that way you don't have to completely revise your code!

Your assignment is to implement a basic inheritance mechanism to extend the main OOP programming project. You will have noticed that the class definition format I gave for the core assignment included a "placeholder" for parent classes. In principle, implementing inheritance is simple: you simply put the name of a (single) parent class into this slot; all instances of the class thereby inherit all methods and instance variables from the parent class (and its parent class, if applicable). In short, it works just like most modern OOP languages. Some specific characteristics:

Implements single-inheritance only. You may not put more than one class in the parent slot.
You may assume that parent class definitions will appear in the class definition file before definitions for any child classes. Depending on how you implement inheritance, this could be a big bonus: your system will "know" about any parent classes before encountering the defn for a child class that references the parent. (Hmmmm....how could I leverage this?...)
There are no "static" (class) fields/variables. That is, all inherited fields are instantiated in each instance.
You must support shadowing --- if a child class defines a method with the same name and number of args as a parent, the child method over-rides the one in the parent class. Shadowing works the same way with ivars: If some class and its ancestor define a field with same name, the definition in the local class is used (only really relevant if the ivar has a default value: the local initialization overrides the inherited one).
Any child class definition must provide for all constructors args of all parents. Thus, if a parent class defines/needs constructor args X and Y, then a child class must also require constructor args X,Y --- plus any additional ones it wants to define. This fits our overall philosophy of inheritance as a strict extension of parent class functionality in children.
Make sure that the THIS keyword still works. That is, when you define a method in a parent class which references THIS, the object that THIS points to depends on which class is instantiated: the parent class or the child class.
If you process class definitions, then change (re-define) the class definition of a parent class later, the children DO NOT have to dynamically reflect this change. That is, if you change classes, you must re-load the whole system to get the changes to propogate through the class hierarchy.

Here is a sample run showing some of the inheritance features at work with the simple Point and 3dpoint classes in the class definition sample linked above. When you have that running, here is a more challenging set of classes (more similar to what I'll test with) that explore the full capabilities of inheritance.

If you have further questions about specification details, please come ask me...

Comments:

Some words on how to tackle this challenge

You should, as always, begin by thinking the problem through carefully!!! The central question, in particular, is "How can I model an object in Scheme?". This will lead you to consider, in more profound ways than you ever have before, the question: What is an object really? Once you boil your understanding down to the primal essence of what an object is, you will find that it is very simple to model in Scheme.

So here is my suggested implementation plan:

STEP 1: Think about what an object is, how to model one in Scheme. Then follow up and directly define an object for yourself --- just make an "instance" directly. Just one for now. When you have understood and managed this, you will have dealt with the central conceptual piece of this programming challenge! Practically speaking, this will allow you to work the kinks out of being able to pass messages (ie, run "methods") and so on. Here's a hint to get your started: Scheme is a statically-scoped language, which means that all functions/variables are evaluated in their environment of definition, which is to say, the variables/names that existed at the time the lambda that defined the function was executed. Which means that, in order to support this stringent requirement, Scheme has to keep that environment around in some way --- hence the name "procedure object", ie, it contains not only the procedure, but its environment of definition. And THIS is exactly what we're going to leverage to implement objects -- we'll just make these procedure objects work as real objects! I'm probably giving way too much fun away here, but here is the basic concept:

Welcome to DrRacket, version 5.0.2 [3m].
Language: Pretty Big; memory limit: 128 MB.
> (define basics 
  (let ((x 2)
        (y 3))
    (lambda () 
      (display (list 'xval: x 'yval: y)))))

> (basics)
(xval: 2 yval: 3)
> >

Is this is coolest thing, or what?! You see how it works? I enclose the call to lambda (which defines the function) within a LET statement, which defines an extended environment of definition for the function. Because the LAMBDA is defined within the LET, the variables defined in the LET are valid and exist at the moment the LAMBDA is defined. So --- to preserve static scoping --- Scheme wraps them up as part of the "environment of definition" for the LAMBDA, which is then tucked into the procedure object that's returned. (Wow, so cool...hmmmm....I wonder if we could leverage this same coolness to define ivars for our objects?!) Of course, the LET ceases to exist right after the lambda is called --- but the environment it defines must stick around because the body of the lambda MUST have access to its environment of definition. Thus, this is the ULTIMATE secure object; only "methods" defined in the enclosed lambda can "see" the ivars defined in the LET! There is no way to violate this hiding, even if you wanted to because the object's security is driven by the scoping mechanisms/guarantees of Scheme! Awesome! SO so cool!

Ok, I think you can take it from there. Obviously you'll need a more sophisticated mechanism for what we technically call "message dispatch" --- dealing with "messages" sent to the object so that you can invoke various methods, deal with shadowing, accommodate the *this* concept, and so on. But this gives you the golden seed...

TAKE THE TIME TO UNDERSTAND everything in step 1. Make some basic objects that accept simple messages, then make the message processing capabilities fancier, deal with multiple signatures for same method name --- all that stuff. Only when you fully understand this are you ready for step2!

STEP 2: ask yourself: how could I write a function that would produce such instances in mechanistic fashion, i.e., an "object factory" --- so this thing basically has to put together the code you wrote by hand in Part I, then eval it. It is, of course, this factory that is invoked by the call to your new function. Follow up by writing yourself an object factory that produces a particular type of object. This will allow you to work out the kinks in passing in values to this factory function for it to use to initialize the "instance variables" for the new instances it produces.

STEP 3: once you've figured out how to write the "object-factory" manually and have it satisfactorily producing instances for you, then it's time to address the by-now rather ho-hum matter of automatically assembling and defining these object factory functions from the class definitions that you read in from the file. This will be a fairly simple matter of combining the list-munging skills and the Function-Maker effort you mastered in Program #1.

Here are some PRACTICAL POINTERS that introduce some Scheme features that you'll probably find useful for this assignment.

To Turn In:

Hardcopy packet: cover sheet, brief overview of your functions for each part, examples of your code in action on test input, and hardcopy of the code itself. In that order. Your cover sheet MUST also include your NAU login name!! (this allows easy matching to your e-submission)
Electronic Submission of your code. Important details:
- Make sure you have a comment header inside your code file, at the start, with NAME, COURSE, ASSIGNMENT, and DATE.
- Submit ONLY your code file electronically; the rest is in the hard copy packet.
- Please put code for all the parts all in ONE file --> so I load that file and all of your functions for all three parts are defined and ready to go.
- Please make sure your functions are named EXACTLY as specified, so that my testing program can call them!
- Name your code file as follows: <Last Name>-<login>-396-OOP === So mine would be "Doerry-edo-396-OOP.rkt"
- Email your submission to me with the subject line "CS396 Submission: <file name>" == So my subject line would be "CS396 Submission: Doerry-edo-396-OOP.rkt"