dburgun at dsl.pipex.com
Sat Mar 25 10:31:42 CST 2006
Not really, you can have any object "Listen", for instance you could
have the Group or the Card or the Stack Listen and then the message
will be sent to that Object instead. You would then process the
objects "below" the current object.
Also you could have all handlers in the control call a common routine
in the stack, card, group or in a library. Just because the Control
handler is located in Object script doesn't mean it can't call code
located elsewhere. Using ISM you get the best of both worlds.
On 25 Mar 2006, at 16:19, simplsol at aol.com wrote:
> Dave Burgun wrote:
> I don't see how my way of doing things is in anyway not a standard
> xTalk approach. What we are talking about it the basic Object-
> Oriented programming. The concept of keeping all the house keeping
> of an object in that object and not spread across many different
> Actually the way you do it ignores one of the most powerful
> aspects of OOP in xTalks, "inheritance".
> If a unique object has a unique handler there is no harm in
> putting the handler in that object. But if the same code is being
> used by multiple objects it helps in many ways to centralize it:
> 1. it is easier to update
> 2. it is easier to debug
> 3. it is easier to maintain
> 4. it is more reliable (it works for all objects or no objects -
> not just some objects)
> 5. you won't accidentally forget it on a new object
> 6. etc.
> One of the problems in xTalk scripting is that handlers can be
> spread across multiple objects anywhere in the message path. Makes
> it hard to debug some else's code - or even code I wrote myself
> last year. Using central library scripts help solve this.
Yes I do this too! ISM doesn't stop you from doing this!
> Your concern about looping through all of the objects on a card
> (or even all of the cards in a stack) does not, in my experience,
> outweigh the benefits of the central library. Modern computers with
> RISC chips are optimized for repeat loops, they do massive repeats
> in milliseconds (I can update all of the 300+ fields on a card in
> 82 milliseconds - and today's computers are twice as fast as mine).
This way you can have a Centralized Library AND NOT have to loop thru
the objects! You get the best of both worlds!
> You are certainly free to use what works best for you or what you
> are most comfortable using but I think Jacque offered excellent
> advice. I'd like to see this as a "style" section in future
> documentation. I wish I had started using this approach instead of
> "learning the hard way".
In my experience I can develop apps much faster using my approach and
none of the points above apply, since I use them *AND* have
centralized control. But see the case study I have posted if you are
All the Best
More information about the use-livecode