Transcript and Dot Notation

[Robert Brenstein]

>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! :)
>

Well, I kept out of this discussion so far, but this post stroke a chord.

May be instead of discussing dot notation virtues versus purity of 
Transcript, the thing to discuss first should be what true OO would 
bring to Revolution. In other words, what is missing in Rev from OO 
paradigm that would truly benefit MAJORITY of Rev users? Do we really 
need full OO stuff? May be the current pseudo-OO with some new parent 
type object and some construct parallel to get/setprop for functions 
can suffice.

Having OO stuff just for the sake of having (that is marketing) is 
pointless in my mind since IMHO Rev will never (at least not soon) 
compete directly against C++/Obj-C and others in enterprise or 
commercial development. Among its winning aspects are RAD features 
and ease of cross-platform deployment, but IMHO it is not 
particularly suitable for development done by larger teams, so some 
of advertised OO advantages are sort of moot.

Robert