On Fri, Sep 21, 2012 at 11:30 PM, Nathan Kurz <[email protected]> wrote:
> On Tue, Sep 18, 2012 at 11:16 AM, Marvin Humphrey
>> The proposal on the table isn't any more complicated than a struct. The way
>> the fields are laid out in memory is identical.
>
> While the second sentence is true, I strongly disagree with the first.
> The cognitive load is extreme.
I don't think that Nick's proposal is hard to understand. Member variables
are still accessed via a struct; the interface change is that you have to look
up that struct first.
Before:
Foo*
Foo_init(Foo *self, int i, float f) {
self->i = i;
self->f = f;
return self;
}
After:
Foo*
Foo_init(Foo *self, int i, float f) {
Foo_IVARS *ivars = Foo_GET_IVARS(self);
ivars->i = i;
ivars->f = f;
return self;
}
In my view, the biggest downside is that the extra code to look up the struct
is irritatingly verbose. It's analogous to `my $self = shift;` -- not hard to
grok, just tiresome to write over and over.
> I worry we'd just be recreating C++ badly here. What are you reasons for
> not just making the jump at this point?
As argued upthread:
I think it's an outmoded approach in the era of CPAN, rubygems, etc. The
fragile coupling of C++ is poorly suited for distributed development and
dynamic linking.
I also happen to agree with classic critiques of C++ as baroque and
overwrought, but my main objection to to C++ is that it is difficult to
integrate with dynamic language ecosystems -- and the fragile base class
problem is a big part of that.
With that as background... does it make sense now why I'm so vehemently
opposed to saddling Clownfish with what I see as one of the most problematic
flaws of C++?
> The part I'd prefer not to give up is the ability to reason about the
> efficiency of a routine by eyeing the source.
I understand this concern, but it seems to me that the lookup routine is quite
transparent -- to a fault, arguably. We're certainly not hiding the fact that
the extra lookup is happening.
> While I appreciate the intent, and think I understand the "Fragile Base
> Problem" pretty well, I don't think it's pressing issue to allow member
> variables to be added ad libitum to the core classes.
We're at an impasse, then. I'm fundamentally opposed to publishing a
Clownfish C API where all instance variables are exposed as struct members.
Marvin Humphrey
