To Rev or not to Rev

[Rob Cozens]

Frank, et al:

>Before someone goes and says, "but we have inheritance -- the group 
>intercepts messages not received by objects in the group, the card 
>receives from the group, etc." -- there is a certain level of inheritance 
>in place, and Rev does have many characteristics of an object-oriented 
>language.  But I for one would not pretend to call it an actual 
>object-oriented language until we can define our own classes, subclass 
>those classes *and* the built-in classes (such as button, field, group, 
>card, stack...), and so on.  There needs to be a degree of 
>scripter-defined polymorphism present, as well.

I must admit that I fell prey to this line of thinking for the longest 
time, feeling "Give me an OOP concept, and I can script that 
functionality."  It took me some time to realize the difference is that the 
functionality is already built in to the OOP when you open the box.

Still, one can script much of OOP functionality fairly easily, and one is 
not prevented from incorporating OOP concepts in one's design; so I'd label 
RunRev as "quasi OOP".

Example: if Frank's example involved changing a button's name instead of 
its label,

on nameChanged oldName,newName
   if char 1 of newName is not a number then set the name of me to oldName
end nameChanged

Rob Cozens CCW
Serendipity Software Company

"And I, which was two fooles, do so grow three;
  Who are a little wise, the best fooles bee."

  from "The Triple Foole" by John Donne (1572-1631)