On Thu, Aug 20, 2009 at 7:25 AM, Jesse Luehrs<d...@tozt.net> wrote:
> On Thu, Aug 20, 2009 at 06:56:11AM +0100, Piers Cawley wrote:
>> On Thu, Aug 20, 2009 at 4:40 AM, Jesse Luehrs<d...@tozt.net> wrote:
>> > This failed because Child was being created and immutablized partway
>> > through the definition of Parent, and so Child's constructor (among
>> > other things) was incorrect (it didn't include attribute
>> > initialization code for the child attribute). This branch adds a
>> > warning whenever someone tries to call make_immutable on a class whose
>> > ancestor classes are not already immutable. There are a few caveats:
>>
>> I'm not familiar with the code, but would it be possible to remove the
>> warning and, instead attach some kind of memento to the parents'
>> metaclasses which will freeze the child class once the last parent has
>> become immutable?
>
> Having the child class silently not become immutable in certain cases
> when you call make_immutable seems wrong, to me. How do you know the
> parent classes are ever actually going to be immutablized?
You don't, obviously. I'd argue that make_immutable is, in fact,
poorly named - it seems overly imperative and bound up with
assumptions about implementation. Surely it would be better to have
something more generic, say:
__PACKAGE__->meta->finalize_definition; # Terrible name
which has the effect of making the class immutable where possible. And
if, in the future, we find a better way of closing a class which
doesn't involve immutability it can still be triggered off
finalize_definition.
However, given the mindshare that make_immutable has by now, that boat
has probably sailed.
