__CLASS__ in child classes

# Fully-Qualified Typename to Universal Main-Derived Typename
func fqtn_to_umdtn (String fqtn) -> String {
  (/^Sidef::Runtime::\d+::(main::.+)$/ =~ fqtn)[0]
}

class A {
  method getclass (scope) {
    say "\t__CLASS_NAME__: #{__CLASS_NAME__}"
    say "\tself.class:     #{self.class}"

    say "\ti am precisely a __CLASS_NAME__: #{self.ref == __CLASS__.ref}"
    const own_type = scope( fqtn_to_umdtn(self.ref) )
    say "\ti am precisely a self.ref:       #{self.ref == own_type.ref}"
  }
}

class B < A { }

say "A:"
A.getclass( { eval(_) } )
say "B:"
B.getclass( { eval(_) } )


A:
	__CLASS_NAME__: A
	self.class:     A
	i am precisely a __CLASS__: true
	i am precisely a self.ref:  true
B:
	__CLASS_NAME__: A
	self.class:     B
	i am precisely a __CLASS__: false
	i am precisely a self.ref:  true

It makes sense why __CLASS__ and __CLASS_NAME__ are defined at the place they exist in the source code, rather than the place they are referred to in the class hierarchy. However, it would be useful if there were a way to know the class / name of the class where a method is being called inside of, instead of simply where it was declared.

obj.is_a(__CLASS__) is not precise enough when you want to test whether an object is exactly your own class, because it will return true if self inherits from obj but not whether they are exactly the same class. Checking __CLASS__.ref == obj.ref would work if __CLASS__ was initialised per-child class instead of per-parent class.

Having to use eval for this (and especially having to deal with eval's very legitimate, but inconvenient scoping rules), is kind of unfortunate.

Perhaps __INHERITING_CLASS__ and __INHERITING_CLASS_NAME__ (or CHILD_CLASS?) could be introduced, so they are only defined within classes, and they evaluate to the full type named by self.ref (rather than the string) at that point in the code?

Start with the reproduction shown in the issue, focusing on CLASS, CLASS_NAME, inheritance, and method dispatch. Determine how a child-aware class value should behave for A and B, then define the desired behavior for the proposed child-class variables and verify it against the displayed comparisons.