Correct Syntax???!!!

[J. Landman Gay]

David Burgun wrote:

 > But then you need to change the script each time you add a new object
 > that needs some specialized initialization.

In a centralized location. With your method, you need to change the 
script of each object. In either case, you have to change a script. I 
don't see much difference there, except that in your case you have to 
remember every object that has a listening script and change each one. 
And you also have to add an extra handler to each object script that my 
method doesn't require.


 > Also you need to ensure
 > that the script is copied onto all cards in your Stack, meaning that  if
 > you have an object of type "X" that needs initialization of type  "Y" to
 > ensure that the scripts of all cards containing *that* type of  object
 > are changed.

This is where I think you misunderstand object inheritance, message 
hierarchy, backscripts, libraries, etc. You don't need to make any 
changes with my method except to one script in a central location. You 
do not need to add scripts to any new objects. You don't need a card 
script for each card. As a matter of fact, adding individual scripts to 
any object is exactly the behavior my method avoids.

 >
 > Using my method, I just drop the new Object into one card, get it
 > working, then wherever I want to use that in another card or stack I
 > just paste it in and it works! I don't need to change anything else
 > anywhere!

Maybe I still don't understand what your method does. But I believe my 
method is identical, except that I don't need to get the new object 
"working". It just works without any scripting of its own, provided it 
is supposed to do what other similar objects do.

 > The script is a property! So we are actually doing the same thing!

Not exactly.  A script needs to be written and debugged; as you say, you 
need to get it "working". A property like the name simply has to be set 
once. There is no chance for error.

 > But you are now visiting all the objects whether they need to be
 > changed or not or you are specifically hard-coding object names into
 > the script so if you delete an object or add a new one, you have to
 > change the script.

No, there is no hard-coding of object names in the script anywhere. That 
is always a bad idea and always to be avoided. And the script example I 
posted deals transparently with new objects, deleted objects, and 
existing objects. You don't have to do anything.

As for visiting each object, this isn't much of an issue given 
Revolution's engine speed; I have successfully updated thousands of 
objects in a preopenstack handler in only a few ticks. With your method, 
there must be some way for the "listening" objects to know they are 
supposed to listen. The only way you can do that without scanning all 
objects in the stack is to keep a list somewhere of which objects need 
to be triggered, and use "send" to send an instruction to each object in 
the list in order to trigger that response. The "send" command has a 
high overhead; I'd guess that with a long list of objects to trigger 
your method could take as much time or longer than a simple repeat scan. 
Another disadvantage to keeping such a list is that you have yet another 
detail to maintain in your setup.

 > This is what I was trying to avoid. I just want to
 > be able to drop a Group or Object into a card and have it work  without
 > changing anything except (maybe) the object I have just  dropped in.

My method works identically. The only difference is that I can use a 
central library that is easy to share with other stacks and I don't need 
to change individiual object scripts or debug them.

 >
 >> You get the same results, with less scripting and more portability.
 >> In addition, the fields themselves do not need to take any kind of
 >> active "listening" role at all, nor do they need any particular
 >> scripts; they need do nothing. All the updating is handled in a
 >> single place -- a backscript or similar -- and if you need to  change
 >> the behavior you only need to change the backscript.
 >
 >
 > I really can't see how it's less scripting! I would say my method
 > results in *much* less scripting, since I don't need to do any
 > scripting at all to add a new measurement control.

Again, I think there's a misperception of how backscripts and stack 
scripts use inheritance. My method does not require scripts in any 
object; it needs only one script in a shared location. In a stack with 
100 "listening" objects, your method requires 100 object scripts plus a 
control script somewhere to trigger them. My method requires one script 
located at the root of the hierarchy.


 > Exactly! You have one monster routine that handles everything, and  you
 > have to change it whenever a new object or a new object type is  added.
 > I would say that this is very error prone, since when you  change it you
 > are potentially affecting ALL objects.


No. You have one master *script* -- not one monster handler -- that can 
be comprised of any number of smaller handlers. Each smaller handler 
will manage all objects that share a behavior. If many objects share the 
same behavior, then you have saved yourself many separate scripts in 
individual objects. And any time you add or remove an object that uses 
one of these handlers, you don't have to change the master script in any 
way, nor do you have to add a script if you create a new, similar object.

 > Say you had  objects of type A,
 > B, C but the current card only contained types A  and C. Now you add
 > type Z and change your routine accordingly. You  test it and see that
 > type A and C still work and so does Z. But  without knowing it you have
 > added a side-effect that now stops type B  from working! Two weeks later
 > you add type B and it doesn't work! Now  you have to backtrack and find
 > out that you added a side-effect to  Type B.

This would not happen; the master script does not reside on the card.

I'll snip the rest; I really didn't mean to start an argument. And I get 
the feeling that neither of us really understands the other's method, so 
I probably shouldn't keep talking. I only wanted to point out to those 
who may still be following this that your method adds some overhead and 
a degree of complexity that isn't necessary, and it ignores the native 
message path and object inheritance that Revolution depends on for 
efficiency. Using Revolution's native techniques, I believe, will be 
simpler and more productive. But if you have found a way to do something 
you like, that's fine with me. I certainly have no argument with that, 
and it is proof that Rev can be used in so many ways that it can 
accomodate all styles and scripting techniques. If you like how your 
method works, that's great. Really, I don't have an disagreement with that.

 > I guess it's a different way of looking at something and I guess  people
 > are scared of things that are "different" but there really is  no need
 > to be.

Sigh. No, I'm not scared of "different" things. You've been using xtalk 
for 2 years, I've been using it for 21 years. I have pretty much figured 
out, I think, which methods work best. In my HyperCard days, someone 
told me once that I wrote the most elegant and efficient code they had 
ever seen. I don't usually toot my own horn, but that was something that 
made me very proud. I have spent quite a bit of time figuring out what 
works and I use those methods in my professional work. But I have no 
"fear" of any experimental method you choose to use. I probably won't 
use it myself, as it doesn't seem to be the best use of the xtalk 
paradigm, but feel free by all means.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com