Transcript and Dot Notation

Arthur Urban aturban at qwest.net
Mon Feb 27 01:34:04 EST 2006


Well, certainly Revolution is OO-like, but it's hard for me coming from 
a strong OOD/OOP background to see it as a legitimate OO offering. The 
number one rule of encapsulation seems "broken" most of the time in 
xtalk-like languages. When I have multiple buttons on a card that have 
the same behavior, instead of each button being an instance of a single 
behavior template, the behavior is often divorced from the very 
object(s) it is meant to work with, in favor of residing at a "higher" 
level in the message hierarchy. Not only does this lead to "where is 
that piece of code?", but object reusability suffers, and measurably 
hurting code maintainability as well. At best I can have libraries of 
stand-alone code segments, not behavior and data wedded in structure. 
Further, the "objects" in Revolution often suffer from being tightly 
coupled, usually the sign of bad OOD, but in this case it is also a side 
effect of the reduced set of actual objects (fields, buttons, cards, 
etc.) that are available. However, I'm always surprised by what I can 
pull off with this product; a credit to it's ability to use it's own 
structures in non-traditional means! :)

John Tregea wrote:
> I know this has been a long thread, but...
>
> I am not sure how Revolution ISN't already OO? I create groups of objects to
> achieve some specific task (during my authoring stage) then during runtime
> in the compiled app, I clone that group with the attributes (approx 200 to
> 300 variable states plus user defined properties), rename it to suitable
> name and Voila! OO? No?
>
> Maybe there is more to it from a C++ coders point of view, but I am a H/C
> programmer from way back and the addition of user defined attributes in Rev
> was a real breakthrough.
>
> Regards
>
> John T
>
> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of Dan Shafer
> Sent: Monday, February 27, 2006 1:45 PM
> To: Mark Brownell; How to use Revolution
> Subject: Re: Transcript and Dot Notation
>
> 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 <gizmotron at earthlink.net> 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
>> use-revolution at lists.runrev.com
>> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>   



More information about the use-livecode mailing list