[cfe-dev] Proposal to simplify ObjC Type AST's
snaroff at apple.com
Mon May 25 09:29:35 CDT 2009
On May 24, 2009, at 7:10 PM, Chris Lattner wrote:
> On May 24, 2009, at 1:48 PM, steve naroff wrote:
>>>> I think having a common base class (abstract or not) makes either
>>>> of these more appealing than what we have now.
>>> This composition enables the "protocol-qualified" concept to be
>>> abstract too.
>> Hey Chris,
>> Sounds good to me. I'd simply call it ObjCQualifiedType (or
> I don't see that this adds any value, what problem does it solve?
> Why add another set of multiple inheritance?
Just to simplify the discussion, let's put this suggestion on hold for
now...I don't want it to distract from the more general discussion
> To me, we should have exactly one class for all of this. The space
> efficiency issue can be easily addressed by tail allocating the
> array of protocol qualifiers (as a second step).
Based on your comments in Radar, I knew you preferred having one class
for all this (which is why my first proposal had precisely one class).
After collecting feedback, I was convinced that designing a type
hierarchy that modeled the language seemed cleaner (and was in the
spirit of our existing AST's).
From my perspective, it gives us the best of both worlds (and solves
the fundamental problem of unifying all the ObjC types)...most clients
will simply use ObjCObjectPointerType, however there are sub-classes
if more detail is required.
> If there is a specific reason that lots of clients want to use
> dyn_cast to determine if an interface pointer has protocol
> qualifiers (instead of using ->getNumQualifiers() != 0), we can
> definitely add helper classes for that. I just don't think we
> should make a big class hierarchy for no reason.
In terms of philosophy, I agree with you (less is typically more). In
this instance, I don't agree the hierarchy is "big". There are 6
classes which model the 6 ways you can specify an ObjC type (id,
Interface *, Class, id <>, Interface <> *, Class <>) and 1 abstract
class to unify them. This didn't seem gratuitous to me. From my
perspective, hierarchies get big/complex when they introduce layers/
concepts that have little to do with the domain they are modeling.
More information about the cfe-dev