[cable] CableSwig: Python wrappers don't wrap public member data

[Will Schroeder]

Let me chip in here. I am Kitware's PI (principal investigator) for ITK. My 
technical grasp of CableSwig is high-level, meaning I really don't know 
much :-) But one thing I do know is that open-source is a process. A 
process that the community must continually engage in. To be more specific, 
I think neutral dialogue regarding the strengths and weaknesses of a tool 
enables us as a community to make informed decisions about where to put 
resources. For example, next year we have another generous chunk of change 
to work on ITK (thanks to the National Library of Medicine). With a 
compelling enough argument, adding functionality such as that discussed 
below is an option. But in order for that to happen I would suggest 
motivating the people involved with a carrot, and not by beating on them 
with a stick. And I have to say I react to words like "stink" knowing how 
hard Brad and Bill worked to get this software to its current point with a 
certain fierce gleam in my eye :-)

Please, tell us what's wrong, tell us how you think we should fix it, 
better yet fix it yourself or help us to fix it. And please avoid 
non-neutral smelly words. If we work the process, the process will prevail 
and we will end up with the tools that we want.

Will

At 12:41 AM 9/11/2003 +0100, Charl P. Botha wrote:
>Steven Levitt wrote:
>>CableSwig doesn't wrap public data members? To be succinct, that stinks. I
>>have a specific need to wrap many C structures in Python, and hand-coding
>>the SWIG interfaces is an onerous task. I was hoping CableSwig would do
>>this more efficiently.
>
>Are you sure that you're not exaggerating?  Personally I wouldn't use the 
>words "onerous" and "writing SWIG interfaces" in the same sentence.
>
>>I don't mean to sound ungrateful for the time and energy you and the ITK
>>developers expend in making these tools publicly available, but this
>>(mis)feature, and any other variations from standard SWIG behavior are
>>things that that the ITK developers should have documented and made clear.
>>I might have saved all the time I spent just trying to get CableSwig to
>>build if I had known this in advance.
>
>Maybe you could set an example by writing detailed documentation for all 
>that open source that you've worked so hard on creating and making 
>available to the public. :)
>
>>I think that the question of whether to wrap public data members ought to
>>be a matter of the policy of a particular project. CableSwig should remain
>>neutral on the matter, and offer the feature as an option.
>
>You have two options:
>1. *Politely* ask for advice on how you could go about to make these 
>changes, then make them, test your work and submit patches.
>2. Get your employer to pay Kitware to make the changes that your work 
>requires.
>
>HTH,
>Charl
>
>--
>charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
>
>_______________________________________________
>cable mailing list
>cable at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cable