At 11:15 AM -0400 5/1/01, b_douglas wrote:
> >Your array (list) functions work fine, but you are missing a key
>>concept of object oriented programming. The key is that objects are
>>all about data and code working together. Your "Array Parent" has a
>>fine set of handlers, but that's all it is, a set of handlers. Given
>>what you have shown, there is no reason to create an object since
>>these handlers operate only on the data passed it. They don't share
>>any data.
>>
>>If you really want to do this in an OOP way, you want to have the
>>object maintain and operate on the data. For example, when you want
>>to be able to manipulate items in an array (or a one dimensional
> >list), you could do this:
>>
<snip>
>Irv,
>could this not be used as an ancestor script.
>
>I guess I am coming from this from a javascript Object point of view and
>since there is no array object prototype as there is in javascript I
>intended to make my own.
>
>And if I save the functions in an object, correct me if I am wrong please,
>if I save them in a global object I can access at any time even if I change
>movies, where as if I put them in the moviescript each time I have to load
>them inwith each new movie.
>
>I was basically attempting to create global functions that I did not have
>to load with each movie, somwething akin to what Peter Small was doing with
>his math objects in Lingo Sorcery.
>
>You see in javascript, you can make functions and save them as methods of
>objects, but, and if there is a way to do this other than ancestors, I for
>the life of me can't figure out a way to add new functions as methods of my
>objects.
>
Yes, if you make an object out of these functions, you can then use
them in multiple movies without having to reload them. And yes, I
believe that Peter Small does do this type of thing in Lingo
Sourcery. But this a very odd and obscure way to do this. There is
a much simpler and more straightforward way.
Let's say that you have a project that is made up of a number of
different movies (A.dir, B.dir, C.dir, etc.), where you want to have
access to a variety of different handlers (e.g., your list
manipulators). The easiest thing to do is to do is to create a
castlib that is shared (linked to) by all your movies where one or
more cast members in that castlib contain movie script cast members
for your handlers.
On my large projects, I always create a castlib called GCode (for
global code). In that castlib, I have a movie script called
utilities. In that script, I have all my utility code that could be
needed anywhere in the project. (If you wanted to group handlers,
you could certainly have a movie script called "Array handlers" and
put all your list manipulation scripts in one place here.) I also
put the parent scripts that could be used anywhere in the project
into GCode. Then, all Director movies in the project include a link
to GCode. Problem solved. No need to create objects for simple
"procedural" handlers. And no need for ancestors either. Since the
handlers are in a linked castlib, they are available to all movies,
and they are already "loaded" when you go from one movie to another.
(FYI, I also always have a GAssets castlib, which contains any assets
like graphics, sound, qucktime, etc, that need to be shared by all
movies.)
Hope this helps,
Irv
--
Lingo / Director / Shockwave development for all occasions.
(Home-made Lingo cooked up fresh every day just for you.)
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
