[C++-sig] Re: Pyste bug - static member functions...

[Nicodemus]

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>  
>
>>I believe that in this context, "final" has the same meaning as in
>>Java... I do not like it much because the meaning is not obvious from
>>the word alone, but perhaps using a familiar term to some other
>>programmers might be better than coming up with a new one?
>>    
>>
>
>Absolutely.  If that's right, I think we should go with "final".
>It's a sensible semantics, too.  There's no reason, once that name
>has been "sealed off" from the overriding mechanism, not to allow
>people to reuse it.
>
 From "Java Programmer's SourceBook: Thinking in Java":

There are two reasons for *final* methods. The first is to put a “lock” 
on the method to prevent any inheriting class from changing its meaning. 
This is done for design reasons when you want to make sure that a 
method’s behavior is retained during inheritance and cannot be overridden.
The second reason for *final* methods is efficiency.

The first definition seems to be what we intend by the mechanism. I wil 
change it in CVS.

>BTW, it seems likely that people will eventually want to do things like:
>      
>      # finalize any functions X inherited from base classes
>      for b in X.bases:
>          for f in b.member_functions:
>              final(f)
>
>Pyste probably ought to expose a slick programmatic interface to the
>XML info underneath it all... or does it do that already?
>

It does not. Currently, the headers are parsed after the user scripts 
have been executed, so what the user is manipulating in the scripts (ie, 
pyste files) is not gccxml information at all. I agree with you, this is 
indeed *very* nice to have, and I will put it in my todo list.