Re: GCC, OOP, and GC...

[<aspiesrule at mcleodusa dot net>]

Sorry, I was a little confused.  Actually, what I was thinking would be to 
move some of the code, (RTL- and tree-printing and optimization would be 
good canidates for this) up into the data structures.


Alexandre Oliva <aoliva@redhat.com> said:

> On Jan 25, 2004, <aspiesrule@mcleodusa.net> wrote:
> 
> > GCC source is _very_ hard to read at times
> 
> Even more so after you remove the line wrapping that is in part
> intended to make it more readable :-)
> 
> > 4.x, a change to OOP would be a _very_ good idea.  With OOP, we could 
move 
> > most (if not all) of the RTL and tree tests into accessor methods
> 
> Guess what, we're already using accessor methods.  It's just that we
> don't always create new accessor methods when we want to test for a
> more complex condition that shows up in a single place.
> 
> In fact, IMHO accessor methods are the very opposite of OOP.  OOP is
> mostly about moving intelligence into the objects, whereas accessor
> methods just give an OOP-look to the non-OOP practice of violating
> abstraction barriers by accessing internal details of objects.  Using
> accessor methods for stuff that is actually there is just exposing
> information about the internals of the object in a way that looks more
> OOP.  In OOP, it's the very notion of exposing such internals that is
> wrong.  If an internal reorganization of the representation of the
> object would require a change in the accessor interface, the accessor
> method gives you no benefit whatsoever, it's just syntactical (if not
> run-time) overhead.  And it turns out that the accessor macros we have
> now accomplish the very goal you're suggesting.
> 
> Sure enough, creating actual code that encapsulate common test
> patterns would be a win in terms of maintaining the overall compiler.
> But that's still not OOP, it's just modularization.
> 
> OOP would be to be able to ask an arbitrary piece of rtl say `do you
> set a hardware reg?' and let it figure things out by itself, using
> dynamic dispatching.  I.e., a parallel would know to descend into the
> various parallels; a set would test it SET_DEST, a clobber would test
> its operand, etc.  But would this really be a win?
> 
> 
> > would allow us to change RTL structures without having to touch all of 
the 
> > code that uses or manipulates RTL, for example
> 
> We already use accessors for everything, so we *could* modify the
> internal structures without modifying code all over.  Which is not to
> say it would be efficient to say adopt compressed rtl, which was
> suggested some time ago.  Higher-level accessors could do it more
> efficiently, for sure.  But it's already be possible.
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
> Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
> Free Software Evangelist                Professional serial bug killer
> 



--