Given these definitions:

  <type name="BaseA">
    <attr1>foo</attr1>
  </type>
  <object name="Obj1">
    <inherit name="BaseA"/>
    <attr1>bar</attr1>
  </object>

what will this code print out?

      msg ("Before Obj1.attr1 = " + Obj1.attr1)
      Obj1.attr1 = null
      msg ("After Obj1.attr1 = " + Obj1.attr1)

The answer is:
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
Before Obj1.attr1 = bar
After Obj1.attr1 = foo

Maybe that was clear to everyone, but it confirms a bit for me how types are used in Quest - and that attribute lookup is done dynamically at runtime.

The reason why this happens is that assigning null to attr1 in Obj1 removes the attribute from that object - and the attribute in the base type then shows through. So... if you have an attribute in a base type, there is *no way* to get rid of it. Ever.

Good discovery, will be useful for anyone who wants to remove attributes, to know about this conundrum, with using object types (inherited attributes).

Setting an attribute to null deletes the attribute from the object. This means that the attribute from the underlying type is now "showing through" the hole left behind. The effect is the same as if the attribute had never been set on the object in the first place.

This is a bug I suppose, but there's no other way of deleting an attribute at the moment, so we would need to think about adding one - and then think about what the effect of deleting an attribute should be in this case too.

To be honest, with all the code I have written so far, that line above is the first time I ever actually deleted an attribute, and that was just to see what would happen. It has never come up so far that I needed that ability. (Perhaps others without a "traditional" programming background will find all sorts of idioms for that, but I just don't think that way.)

I just enjoyed having that peek into how Quest operates.

In my opinion, setting the attribute to null should not delete it. Null is a valid value. I would also like to be able to set attributes of type "object" to null in theb base type so that I don't have to add them to each object manually, and then set their value later in the code or in the editor.

Also, what I would expect if you do delete the attribute would be that the base type attribute does not apply to that object anymore instead of "showing through".

Rationale:
If you can already override the base type attribute value, you should be able to override it existence too.

Just a question: is this a theoretical or a practical problem? I mean Quest is not a all-embracing language like Java or C#, it's a script language of a textadventure creator. I think only 0.01% of all users will use this feature and for this few people it shouldn't be a problem to find an alternative.

Pertex wrote:Just a question: is this a theoretical or a practical problem? I mean Quest is not a all-embracing language like Java or C#, it's a script language of a textadventure creator. I think only 0.01% of all users will use this feature and for this few people it shouldn't be a problem to find an alternative.

If you are asking about attribute overloading, I am not sure what to answer because I haven't given it much thought yet.

If you are asking about the effect of assigning null, to me it would matter what it does.