[cfe-dev] Proposal to simplify ObjC Type AST's
snaroff at apple.com
Mon May 25 12:40:34 CDT 2009
On May 25, 2009, at 12:52 PM, Chris Lattner wrote:
> On May 25, 2009, at 7:29 AM, steve naroff wrote:
>>> 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 below.
> Sounds fine to me.
>>> 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.
> I don't see this. I see this as two orthogonal axes: an "objc type"
> can either have a specified interface or be generic (id) on one axis.
...or it can be a generic class object (i.e. 'Class').
> On the other axis, it can have a variable number of protocol
> qualifiers (0 ... N). Our current breakdown seems very odd to me,
> because there is little difference between the jump from 0 -> 1
> qualifier or from 1 -> 2, yet we model the jumps completely different.
> I really think that we should have one class. If there are clients
> that are greatly simplified by being able to use dyn_cast to tell
> (e.g.) between id and NSString, then we can definitely add helper
> classes. However, this is a syntactic issue, not a representational
> issue: the new classes should not have any contents. Further, I
> really think we should add *at most* two new classes (one for "is an
> id thing" and "is an interface thing") not 6 or 7 or 8.
I agree it's not a representational issue. You clearly feel more
strongly about this than I do, so let's just go with one class...
One question though...how is this issue different than how we
represent function types? Why don't we have 1 class (FunctionType)
instead of 3 (FunctionNoProtoType, FunctionProtoType)? Seems like you
could have methods on FunctionType that eliminates the need for the
>>> 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.
> What clients would use this stuff? Why can't they use
> getNumProtoQuals() or getInterface() != 0 etc?
> This set of classes is complex because you're getting N*M classes
> (with an admittedly small value of M and N).
More information about the cfe-dev