Re: [Arianne-general] Script API

[Ulrich E. <ul...@do...>]

On Thursday 16 May 2002 17:56, Miguel Angel Blanch Lardin wrote:
> class Object;
>
> typedef Object* Object_ref;
>
>std::string const& 
>Object_Get_Attribute(Object_ref const& object, std::string const& Attribute);

You have a little problem here:
   Object_ref const& object
boils down to
   Object * const& object
which is a reference to a pointer whos value you're not allowed to modify 
inside the function. However, no such guarantee is made for the Object it 
points to...
You'll need to add another typedef for const Objects, I think.

>
> /** Refs to our own Object and Action */
> Object_ref Object_Myself();
> Action_ref Action_Myself();
Are these really necessary and do they make sense ? What exactly do you mean 
with 'own Object and Action' ? If you're executing an action, you need a 
pointer to it anyway (as function-argument, I think) and possibly you'll have 
more than one Object that is affected by it ....

There is another thing I noticed: iirc, Object and Action are both derived 
from Attributes (both are a set of attributes/properties). Provide one API 
for that. 
Objects additionally have a set of other Objects nested inside, forming 
(roughly) a tree [1]. Provide another API for that.
The world behaves almost like an Object, the difference is that it will be 
implemented differently to accomodate for different access-needs. 
Nonetheless, one might provide the same API as for Objects to the scripts, 
hoping that no script abuses that ...

The slot-functions are right the way they are, gaining read-access to a slot 
should be performable on a const Object and _not_ return a reference to a 
const Object. While this might seem wrong on the first look, it doesn't 
change much: you can always read the ID from a const Object and ask the world 
for a non-const reference.

> /** World related attributes */
> Object_ref World_GetObject(std::string const& id);
> void World_AddObject(Object_ref const& object);
> void World_DelObject(Object_ref const& object);
> Object_ref World_CreateObject();

What does the last function do ? It creates an Object that is not in the 
World, no? This is a dangerous thing to expose to the script-API. Same is 
true for the delete function.

Instead I'd do it this way:
  /** search an Object with the proper ID in the world. 
  Returns zero if not found. */
  Object_ref World_FindObject(string id);
  /** returns a ref to a newly created Object. */
  Object_ref World_ObjectCreate();
  /** mark an Object as destroyed. */
  void World_ObjectDestroy(Object_ref);

Those three should be enough for the scripts. Creating an Object implicitly 
adds it to the world. Destroying one only marks it as destroyed (the 
reference remains valid) so that you can collect those and notify clients of 
their destruction and finally also delete the C++-objects [2].


uli



[1]: I'm getting nightmares when I think of having to deal with a possibly 
circular structure of this. Should be avoided like hell if not absolutely 
necessary.


[2]: the same should be considered for Actions.