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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
