Once an instance of a perlclass class has had its fields initialised,
it seems to be intended that the identities of the field variables should
never change. To reflect that, I reckon it should be marked SvREADONLY.
This would immediately have one effect on core behaviour. Currently
there's specific logic to prohibit reblessing any SVt_PVOBJ. I think
the intent of that was to prohibit reblessing an object that is
currently blessed into a perlclass class, but it's been implemented
from the wrong end. Such logic ought to be tied to the class rather
than the object representation type. But it's also quite unnecessary
to implement such a restriction as a new feature of bless: it's already
prohibited to (re)bless a read-only object. So making perlclass class
instances SvREADONLY is a better way to restrict reblessing. (Not that
we need such a restriction anyway: reblessing an object away from a
class doesn't threaten the class's integrity.) So I reckon SvREADONLY
marking of instances should replace the specific reblessing restriction.
This issue intersects with the Perl bug that I recently
reported, "initfields CV visibility causes mayhem"
<https://github.com/Perl/perl5/issues/20956>, concerned with the order
of operations around instance initialisation. That bug report came out
of experimentation around what the core's intent was regarding field
variable identities, for reasons related to the present suggestion.
If SvREADONLYness is added for the reasons that I propose here, then the
flag can be used to resolve that bug. The confusion illustrated by that
bug provides additional motivation to use SvREADONLY: it would provide
clear demarcation of when field variables are expected to stop changing,
and would be a status that's easily checked by croaking or asserting code.
Setting SvREADONLY to reflect an intended immutability of instance
structure would also be useful for cooperation with code on CPAN, were
anyone to write a module that uses the SVt_PVOBJ data type. Having the
initfield op type check SvREADONLY in order to honour immutability would
also help in this regard.
Patches attached.
-zefram
it seems to be intended that the identities of the field variables should
never change. To reflect that, I reckon it should be marked SvREADONLY.
This would immediately have one effect on core behaviour. Currently
there's specific logic to prohibit reblessing any SVt_PVOBJ. I think
the intent of that was to prohibit reblessing an object that is
currently blessed into a perlclass class, but it's been implemented
from the wrong end. Such logic ought to be tied to the class rather
than the object representation type. But it's also quite unnecessary
to implement such a restriction as a new feature of bless: it's already
prohibited to (re)bless a read-only object. So making perlclass class
instances SvREADONLY is a better way to restrict reblessing. (Not that
we need such a restriction anyway: reblessing an object away from a
class doesn't threaten the class's integrity.) So I reckon SvREADONLY
marking of instances should replace the specific reblessing restriction.
This issue intersects with the Perl bug that I recently
reported, "initfields CV visibility causes mayhem"
<https://github.com/Perl/perl5/issues/20956>, concerned with the order
of operations around instance initialisation. That bug report came out
of experimentation around what the core's intent was regarding field
variable identities, for reasons related to the present suggestion.
If SvREADONLYness is added for the reasons that I propose here, then the
flag can be used to resolve that bug. The confusion illustrated by that
bug provides additional motivation to use SvREADONLY: it would provide
clear demarcation of when field variables are expected to stop changing,
and would be a status that's easily checked by croaking or asserting code.
Setting SvREADONLY to reflect an intended immutability of instance
structure would also be useful for cooperation with code on CPAN, were
anyone to write a module that uses the SVt_PVOBJ data type. Having the
initfield op type check SvREADONLY in order to honour immutability would
also help in this regard.
Patches attached.
-zefram
