This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Move FIELD_DECL into it's own structure


On Mon, 2005-05-23 at 14:12 -0700, Mark Mitchell wrote:
> Daniel Berlin wrote:
> >>
> >> I looked into some of this in the past too, but I was not so adventurous
> >> as Dan to actually try doing the hard work.  The main reason was that it
> >> is just impossible to determine beforehand how trees are to be split up,
> > 
> > 
> > I plan on documenting *how* i split them up,  how to add new trees, how 
> > to deal with inheritance and checking, and when they should be split up.
> 
> Great; that's exactly what I'm looking for.
> 
> > I'm writing this stuff on the wiki right now.
> 
> I wonder if it might be possible to put it directly into the manual?  I 
> did say Wiki before, so if this is a pain, then I'll help with the 
> translation to TeXinfo.  I'm sorry about switching gears here, and I 
> don't want to be wasting your time.

Well, i posted my current methodology for discovering this stuff and
coming up with a hierarchy, as well as how i split it and my plans for
dynamic type checking at http://gcc.gnu.org/wiki/New%20DECL%20hierarchy

As you can see, i have no large plans past moving out fields that are
easy to move out. If someone wants to do massive restructuring (and
changing all kinds of front end code, etc), that's fine, but i'd rather
have something than nothing, and with the scheme i've described, the
easy stuff is easy to move, and we still can keep dynamic typechecking.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]