"Active Data" is data that takes some active role in its use--reading, writing, modifying, deleting, or using in some activity.
As a point of reference, data in the C sense, ints, floats, pointers, and so forth, are passive. It doesn't matter what's in them, your program has complete control and it doesn't matter what data is in those variables, things always behave the same. What's nice here is that the compiler can predict, soley from the code, what will happen when an operation occurs. It may lose track of the referents to data (if, for example, a pointer escapes the code visible to the compiler) but everything's nicely static, and the only thing actually *doing* anything is the code.
Active data is data that in some way affects program behavior independent (or semi-independent) of the code being executed.
The common case, one most folks are familiar with (if they're familiar with this stuff at all) is operator overloading. Addition may not really be addition, if one or the other of the data in the operation overloads the addition operator. (Whether both sides, or just the left, is checked, and whether the types of both sides matters depends on the language) The compiler can't necessarily tell whether addition is really addition any more--it might really be subtraction, or multiplication, or some bizarre way to encrypt the contents of your hard drive.
In some languages the compiler can at least make some predictions of what operations will do, but we're not really interested in those languages. Or, rather, it doesn't matter if we are or not, since perl, python, and ruby are all untyped so there's not much to be done, and full type inferencing's a halting-problem sort of thing. (Though a useful subset of many programs can be analyzed enough to do some optimization)
Perl, at least, and because of it Parrot, goes one step further. Not only are operations overloaded, but assignment is overloaded. If you're coming from a pure OO sort of language where assignment is just the association of a name and pointer to an object, this may seem kind of strange, but it is really useful.
The canonical example is associating a hash with a database. Reading or writing from the hash does a lookup in the backing database and reads or writes from it. A handy thing, with the variable getting in the way of reads or writes to itself. However, you can do this with plain scalar variables.
For example, if you had code:
int Foo; Dog Bar = new(); Foo = Bar;
you wouldn't want there to be a Dog in Foo--you've declared it an integer, so it can only hold an integer. The assignment can't do a plain pointer copy the way it would in the case where both sides can hold objects.
As an alternate example, try this:
TempMeter kitchentemp = new('kitchenroom');
TempMeter bedroomtemp = new('bedroom');
bedroomtemp = kitchentemp;Where in this case kitchentemp *is* an object, but one of type TempMeter, and bound to an object that represents the temperature in your kitchen, while bedroomtemp is a TempMeter object that represents the temperature in your bedroom. (Code I'd not recommend using in CGI programs....) The assignment does *not* bind the bedroomtemp name to the object for the kitchen temp, rather it sets the bedroom temperature to be the same as that in the kitchen. Even being an object, the object's methods still intercept read and write requests and instead of assignment being rebinding, it's instead a get or set call on the object.
The part that affects us is that we can't tell at compiletime whether assignment is rebinding or is a get/set, because we could have code like:
kitchentemp = new('kitchenroom');
bedroomtemp = new('bedroom');
bedroomtemp = kitchentemp;which is typeless, and yet should still respect the fact that the objects bound to the name intercept assignment (basically overloading it) rather than having the compiler or runtime doing the rebinding for you.
Since, of course, we're dealing with basically typeless languages we have to do all the checking at runtime (lucky us) which is why the PMCs have generic get and set methods so they can decide whether we're doing rebinding or something more funky. (Whether this affects languages where = is an explicit binding rather than assignment is up in the air, but neither python nor ruby is truly that way, though they're close. But we can fake it so that things do what they ought when they ought)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
