Add __CLASS__ keyword

[leonerd]

Also a couple of small neatenings of code/test; kept as separate commits in case of subsequent revert

[leonerd]

Hrm; everything passes except the g++ one which fails:

/usr/bin/ld: globals.o:(.data.rel.local+0xd48): undefined reference to `Perl_ck_classname'
/usr/bin/ld: miniperl: hidden symbol `Perl_ck_classname' isn't defined
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

probably because the newly-added opchecker function isn't done right, somehow. Hrm.

[leonerd]

I can reproduce this locally, and it is fixed by simply moving the Perl_ck_classname() function out of class.c into op.c. Presumably therefore, something isn't expecting to find it in that particular file. Possibly a list of files to expose needs updating? But weird that it only happens under g++ and not regular gcc.

[leonerd]

g++ now fixed. Turns out it needed some extra poking in regen/embed_lib.pl, which @ilmari found. Thanks :)

[Ovid]

Pardon my ignorance 😃 I think ADJUST is currently considered a method, but eventually will become a phaser. It is intended that __CLASS__ will work there?

[leonerd]

Yeah definitely. The ADJUST blocks will become individual blocks that are all still part of one overall containing method, so __CLASS__ still still work fine there. It'll just stop being one method per block.

[Ovid]

The initial design of Corinna was to separate methods and subroutines. Thus, you can't call subs like you can call methods. If we had the :common attribute, this could be written as:

    class WithCustomField {
        method DEFAULT_X :common {10}
        field $x = __CLASS__->DEFAULT_X;
    }

This allows subclasses to override the method with different behaviour.

    class DifferentCustomField :isa(WithCustomField) {
        method DEFAULT_X :common { rand > 0.5 ? 20 : 30 }
    }

[leonerd]

Indeed so. This is the best we can write currently, but once we have common methods we can change the documentation to fit the better design.

[Ovid]

Maybe we should add a note about this in the documentation? If people start writing code relying on this, future releases will break it.

[leonerd]

It's all very new and experimental now anyway. Any of the docs should be read in that light anyway, so I don't think adding specific wording to basically every claim and sugestion is going to be all that helpful.

[Ovid]

Can we add a test verifying that __CLASS__ is available in ADJUST blocks?

[leonerd]

Added, re-testing now.