Re: "gimple-classes-v2-option-3" git branch committed to svn trunk as r217787

[Andrew MacLeod <amacleod at redhat dot com>]

On 11/19/2014 01:12 PM, David Malcolm wrote:

> (A) could become:
>
>    greturn *stmt = gsi->as_a_greturn ();
>
> (B) could become:
>
>    stmt = gsi->dyn_cast <gcall *> ();
>    if (!stmt)

> or:
>
>    stmt = gsi->dyn_cast_gcall ();
>    if (!stmt)
>
> or maybe:
>
>    stmt = gsi->is_a_gcall ();
>    if (!stmt)
>
> An earlier version of my patches had casting methods within the
> gimple_statement_base class, which were rejected; the above proposals
> would instead put them within gimple_stmt_iterator.
I would like all gsi routines to be consistent, not a mix of functions 
and methods.
so something like

stmt = gsi_as_call (gsi);
stmt = gsi_dyn_call (gsi);

or we need to change gsi_stmt() and friends into methods and access them 
as gsi->stmt ()..  which is possibly better, but that much more 
intrusive again (another 2000+ locations).
If we switched to methods everywhere for gsi, I'd prefer something like
gsi->as_a_call ()
gsi->is_a_call ()
gsi->dyn_cast_call ()

I think its more readable... and it removes a dependency on the 
implementation.. so if we ever decide to change the name of 'gcall' down 
the road to using a namespace, and make it gimple::call or whatever, we 
wont have to change every single gsi-> location which has a templated 
use of the type.

I'm also think this sort of thing could probably wait until next stage 1..

my 2 cents...

Andrew