AHLL objects

[Anders Petersson]

I'm continuing the thread from IRC last night. This is much loud thinking.

We want the player [object] to "see" and be able to change certain things 
about his own object, while other things should only be accessible thru 
protected functions. So, we have the problem of restricting a player access 
to his own character (as an example).

Solution 1
----------
One solution is to require some sort of declaration of an object [or object 
type]. All declarations wouldn't have to be complete... the player would 
only get a definition including what he is allowed to do. All subobjects 
are there, unaccessible as accessible ones, but to actually use any of them 
requires you to have seen them in a definition, a definition that we may 
define as we wish.
(The subobjects I'm considering now are things like information on where 
the character is located, his health and stuff (and inventory, for that sake).)

+ Everything can be there without fuss.
- How to gain or loose rights not investigated; another object seems fit 
for storing declarations. This would multiply the object numbers though, it 
seems like.
+ Declarations can be shared, thus reducing complexity and ease making changes.
- A method that needs access to even the smallest thing restricted needs a 
new definition object. (Unless the declaration can be shared, or 
declarations could have additions defined. Or, pointers directly to the 
needed variables/whatever (not the parent object).
+ Perhaps could definitions also contain information about allowed 
operations (could simply depend on declared object type - methods incuded 
as variable (or even constant) could only be evaled, etc.)
+ With definition objects, a member method could simply have a link to the 
parents definition to inherit all rights.

Solution 2
----------
Make objects in levels, so things the player must not access is high in the 
structure, while accessible items all stem from a common branch. The player 
would then not be given a pointer to the "top" of the character object, but 
merely to the common branch. The usual rules says that you see what is 
under an object you have access to, so you get the correct rights while 
everythin is still there. Ofc, functions need to contain a pointer to the 
top structure if they need to do something important (so they get access to 
what the player must not access personally.
+ No definition objects needed - only pointers that give access to 
everything below.
- Objects have to actually be designed with the allowed levels of access in 
mind.
- This design would make objects more complex
- No natural model of fine-grained restriction of access to objects

Comments:
In both models, there is a need for running methods that have access to 
protected variables. You must have right to evaluate the function, but not 
to make changes in it or even see the code contained. And, needless to say, 
the player can't have direct access to the protected variables the method 
functions on, but the method itself must. One scenario is when a method 
simulates a variable - you can take the value of it, without worrying if 
it's a variable or a method.
This is something I've thought about; the default way to get the value of 
something should be to evaluate it; this would return the direct value of a 
variable or constant, and if the object is a method, run it to return the 
computed answer.


Example of solution 1:
---------------------
TargetObj = (
   method isUp = (
     if(light):
       return eval(see-if-up)
     else if(dark):
       return eval(feel-if-up)
   )
   method doThis = (
     or-whatever
   )
)

Def = (
   variable isUp
   method doThis
)

Me = (
   <link-to TargetObj> as <link-to Def>
   f = (
     if(TargetObj.isUp):		//According to what 'Me' knows from 'Def', 'isUp' 
is just a variable
       print('Yes, target is up.')
     for x in TargetObj.doThis:	//Select each line in method doThis in order
       print(x)
   )
)

The ahll interpreter must have access to some kind of complete definition 
of all objects. It would then choose an action depending on how the 
caller's definition fit with the real definition. Or maybe that is rather a 
job for the compiler (compiles into the object format).

Function vs variable
--------------------
functions could be treated as variables if the following rules were there:
f = x   =>  eval(f(x))
y = f   =>  y = eval(f)
f == x  =>  if(eval(f(x)))
..and no compiler optimizations are made. ('eval' here is just to denote 
that the function is run instead of used as a data structure.)

binEng