many small or 1 big?

Richard Gaskin ambassador at
Sun Sep 8 12:57:01 EDT 2002

mark mitchell wrote:

> I wonder if I might get the lists input on an overall design question.
> I've been making dozens of little applications.  This comes from the
> hypercard mindset, wherein you have a single player and then you can
> have all the separate stacks you want.  The problem with revolution was
> that stacks alone did not run so well without the development
> environment fired up.  So as I made stacks, I converted them to
> standalones.  This was working fine, but I had envisioned that I would
> one day make a single "table of contents" app, that could be used to
> organize, explain and launch all the little apps.  As I went along
> however, I realized I sometimes had 4 or 5 of these little apps running,
> and they must each be using an identical engine and wasn't that silly
> when they could all be using the same?  So I made a single 'table of
> contents' standalone and stuck all the former app data stacks in it.
> But now I'm not sure which was really better, this 1 big, or the
> previous many little?

If the apps are related, or if new ones may be added by downloading the,
then the 1-Big option seems optimal.

If they share no related functionality it may make more sense to ship them
as separate apps.

As for globals, if you use static vars (what the Rev docs call "script
local") you completely avoid name-space conflicts. Sometimes you truly need
a global, but most of the time the data is only shared among a few handlers
and if these handlers resode is the same script then static vars would work

Custom propeties are also useful for this, with the additional benefit of
binding data to specific objects.

Sounds like a good case for a Rev Player....

 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 2.0: Publish any database on any site
 Ambassador at
 Tel: 323-225-3717                       AIM: FourthWorldInc

More information about the Use-livecode mailing list