Before Lingo adopted dot notation, it had an intermediate parent-child
"xTalk varietal" approach. I've forgotten now how it worked but I
recall it was hard to learn and very slow.
That may or may not have any bearing on this design, however.
On 2/26/06, Mark Brownell <[EMAIL PROTECTED]> wrote:
>
> >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?
> _______________________________________________
> use-revolution mailing list
> [email protected]
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer, Information Product Consultant and Author
http://www.shafermedia.com
Get my book, "Revolution: Software at the Speed of Thought"
>From http://www.shafermediastore.com/tech_main.html
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
