Discussions
Solve problems, and share tips and tricks with other JMP users.
Accepted Solutions
I apologize for taking so long to respond. I'll give an example of a "class" definition, and its use, for the example you provide. It is important to consider if you would want/need this. As you pointed out, "when would you decide to make a new class?" As you may recall from my presentation, I suggested that project size, collaborative development, longevity, need for reuse, etc. should be considered before determining if OO constructs are the best approach. I will respond to msharp's comments with more on that topic.
Back to your example. Using the ObjectClass as a parent class, although not required, we could create a DataTableClass:
Usage of the fields for DataTableClass instances would look like:
For such a simple example, there would no reason to use the OO constructs. However, if you were to consider a case where you wanted to manage collections of tables, enable users and external systems to add comments and other attributes, pass these collections around, process and respond to given events, plan for future expansion and extension, establish a "contract" by which others can easily consume these tables, etc. Then, using OO constructs such as these are very beneficial.
I know drewfoglia already answered your question, however, I was in the midst of crafting a response so I'll just put it forth for what its worth.
First, in my opinion the datatable itself can already be thought of as an object.
dt1 = NewTable() - Creates new "instance" of Datatable
ShowProperties(dt1) - Show all the "properties" and "methods" for the Datatable object dt1.
One can think about "extending" the existing Datatable Object with additional properties and methods, as in Drew's reply. I thought about having additional features like:
1. Rowstate Handler.
2. Column and Row, Add/Delete detection.
3. Table cell change history.
4. Databox (Displaybox)
So, a possible "constructor" for the DatatableObject could look like, where member variables and functions are declared. (note the Expr( New Namespace() ).
The idea behind declaring the object this way, is not only establish a replicable entity, but also allows one to clearly see the functions and expression names that will become usable once they are fully defined.
My version of the NewDatatableObject (partial listing). Here is where the member functions are actually defined:
So for example, we create 2 separate instances of DatatableObject:
These tables now have "extended" properties built-in. In this example, some table actions are tracked, such as detecting row selection and Column/Row deletions.
One can imagine a host of other useful functions as well, that could be implemented using this method.
I apologize for taking so long to respond. I'll give an example of a "class" definition, and its use, for the example you provide. It is important to consider if you would want/need this. As you pointed out, "when would you decide to make a new class?" As you may recall from my presentation, I suggested that project size, collaborative development, longevity, need for reuse, etc. should be considered before determining if OO constructs are the best approach. I will respond to msharp's comments with more on that topic.
Back to your example. Using the ObjectClass as a parent class, although not required, we could create a DataTableClass:
Usage of the fields for DataTableClass instances would look like:
For such a simple example, there would no reason to use the OO constructs. However, if you were to consider a case where you wanted to manage collections of tables, enable users and external systems to add comments and other attributes, pass these collections around, process and respond to given events, plan for future expansion and extension, establish a "contract" by which others can easily consume these tables, etc. Then, using OO constructs such as these are very beneficial.
Hello, Philip
It's very subtle. If you look at line 30 of the DataTableClass definition, you'll see this:
super is being defined as a local variable (scoped to the lifecycle of the function) and is being assigned the DEFINITION of the already existing deleteChildReferences function.
Read that again.
Let me say it another way. There is already a function, deleteChildReferences, on the namespace (defined in the ObjectClass.jsl that is included and gets assigned when the ObjectClass:newObject() call on line 6 executes). In the DataTableClass, line 29 is replacing that assignment. However, in the process of reassigning, we are creating a local variable "super" that is holding a reference to the original function definition - the one declared in ObjectClass. In this way, we are overriding the behavior of that function, adding code to close the table reference in this case, and then still able to call the original function declaration using the super() call.
