[C++-sig] Re: Pyste: support for user defined code.

Nicodemus nicodemus at globalite.com.br
Mon Aug 18 00:22:35 CEST 2003


David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>  
>
>>declaration goes inside the empty namespace, together with the wrapper
>>classes for instance. global declaration goes outside this namespace.
>>    
>>
>
>That seems very redundant.
>
>    global_declaration_code('''
>    namespace {
>        ...
>    }
>    ''')
>

Agreed, no need for two kinds of declarations... it will only add to the 
confusion.

>>>>module_code()
>>>>   
>>>>        
>>>>
>>> hello.inject('''
>>>       // my C++ code here
>>> ''')
>>>
>>>  hello.World.inject('''
>>>       // my C++ code here
>>> ''')
>>> 
>>>      
>>>
>>I assume "hello" is the module name. That doesn't work because a Pyste
>>file doesn't know in which module it will generate the code (this is
>>given in the command line). 
>>    
>>
>
>I based the suggestion on your example from the Pyste docs.
>  
>

Oh, then you meant a header file. Yeah, it is possible, although I 
prefer the code() functions... but that's me.

>>Assuming "hello.World" is a class, then "inject" will put the code
>>before or after the class? 
>>    
>>
>
>Within?
>
>     hello.World.inject('.def("foo", ...)')
>  
>

Oh, haven't thought about that. Seems useful, but to keep consistency we 
should make that a free function, not a method, because that is the 
syntax used to access World members (for instance, if the class World 
had a method "inject" that the user wants to exclude, the syntax would 
be "exclude(World.inject)").

I propose:

inject(<class>, <code>)
inject_code(<class>, <code>)

Althought I preffer the latter.

>>I find that a code() call more clear than an inject method.
>>    
>>
>
>"declaration_code" seems a little redundant to me.  Aren't all
>declarations code?
>

That is to keep similar to "module_code", but I agree it is a little 
redundant. Opinions?

Thanks for the feedback Dave!

Regards,
Nicodemus.







More information about the Cplusplus-sig mailing list