Transcript and Dot Notation

[Mark Brownell]

>On Feb 25, 2006, at 10:59 PM, Scott Kane wrote:
>
>>> What do dots enable that
>>> Transcript does not?
>>
>> Properties and methods.
>
>Objects can already have properties, and methods as well. They can't  
>have _inherited_ methods -- at least not in the traditional IO sense.  
>An object inherits methods from its enclosing groups/card/stack.
>
>And indeed, as I incautiously said in another email a moment ago, I  
>think I could implement something very like class methods using a  
>front script.
>
>
>------------------------------

Perhaps a few of you around here will find this funny, I could do an implementation of OOPs with a pull-parser.  The trick to creating a child object is to assign attributes of the parent object to a child object. What is needed during the birthing process is an allocation of memory to store the newly incarnated child and to act on it independently while effecting the parent that can also have global changing effects if desired. 

Objects of the element type <parentObject> sets and child objects like <childObject memLoc="1"> sets or child  objects like <childObject1> & <childObject2> can be stored in arrays. There could be a function written with Transcript that uses elements of the parent object to create child versions that are stored in an array and that are called at memory locations 1, 2, 3, etc.

An example parent object could have attributes for width, hight, color, category, etc.

<parentObject>
  <typeObject>field</typeObject>
  <name>Test Object</name>
  <width>variable</width>
  <hight>variable</hight>
  <loc>variable</loc>
  <scroll>yes/no</scroll>
  <title>Parent Object Test</title>
</parentObject>

A function of birthing a child object would come from attributes found in the parent object while passing values during creation.

put birthChildObject("Test Object", 200, 300, "21 by 56", yes, "Test Field One") into pObjectArray[1]. The rule being that elements found in the parent object are located in the function as a descending order.

There would be support functions that would create the XML, change the XML, and parse the XML so that methods could be created to interact with the child objects found in pObjectArray[1]

There could be a function to change a variable value in the width element to a fixed value that can have a global effect on all child objects. This would transform the width element in each child or it could have an overall function of following the parent and ignoring the individual values in each child.

All that is needed is the ability to perceive or anticipate the parent. So a completed construct to anticipate known attributes needs to be made available for type elements. This leaves non-keyword elements for new, unknown parent objects or elements.

Crazy huh?