Suggestion

[Richard Gaskin]

Hershel Fisch wrote:
> On 6/4/07 5:43 PM, "Hershel Fisch" <hershf at rgllc.us> wrote:
> 
>> On 6/4/07 5:21 PM, "Richard Gaskin" <ambassador at fourthworld.com> wrote:
>>> The "rev" prefix helps identify calls that are not natively supported by
>>> the engine, requiring additional libraries and/or externals.
>
> And by now, why isn't it built in direct into the engine?

The question of dividing lines is central to so many architectural 
questions in computing.  In this case, setting the dividing line between 
what's in the engine and what isn't, the general impression I get is 
that the more frequently it's needed, the more likely it is to go in the 
engine.

The benefit is that it keeps the core engine small (2MB is smaller than 
even the most trivial apps Apple puts out), while still allowing 
additional functionality for those apps that need it.

That said, I use player objects in only about half the apps I build, so 
maybe QT support is a good candidate for being outside the engine.

Ideally, we might one day see almost everything outside of the core 
interpreter made into a modular architecture, so that small utilities 
could be even smaller than they are today, while more complex apps could 
have their needed components added automatically at build time.

If/when such an architecture emerges, I would definitely support 
dropping the "rev" prefix, since at that point most things would be 
"outside the engine" because the engine itself would become a 
fundamentally different thing.

But in the meantime, libraries and externals require extra steps to set 
up and use, so having a means to clearly distinguish their APIs is helpful.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com