Re: [Gtk-osx-users] Segmentation fault accessing widget props

[Richard Procter <richard n procter gmail com>]

On 1/12/2010, at 5:59 PM, John Ralls wrote:

> 
> On Nov 30, 2010, at 5:14 PM, Richard Procter wrote:
> 
> That's a new "feature" of Gtk and GLib. You aren't allowed to access properties directly any more, you have to use the accessor functions. If you look in the C source code, you'll see GSEAL all over the place. It's the "we can write OO code in C, yes we can!" version of the private variables in real OO languages. (Yes, that's a slam at Python, because van Rossum doesn't believe in data hiding. He's wrong and Stroustroup's right.)

You know, I was thinking on the way home tonight of that saying "if you try to write an OO runtime you'll end up reinventing C++, badly". I'm not certain that it has to be C++ but it does seem to me that writing a custom OO layer is asking for trouble simply because a) it is in itself so difficult to do well and b) really deserves language support and, further, c) it will be written as a means and not as an end in itself and so will be liable to all sorts of 'pragmatic' compromises in the heat of the moment that create nasty unforseen side-effects, path-dependencies, and plain old unnecessary complexity. And few people will want to maintain the resultant hairball. 

I was also thinking that the whole shooting box would have been better off written in objective-C or C++. If I remember right, the compiler support was there back in the day for both languages. And, from my tiny experience of pyobjc, it seems that objective-C has the facilities for good introspective bindings. And NeXTSTEP was extant at the time, and probably GNUstep, too. 

Anyways, it's easy to criticise in hindsight, etc, etc. Show us the code, etc, etc. /End of Rant. 

As for private variables - that's an interesting discussion in itself! I'll have to look up GvR's rationale for that design decision sometime. I agree that the C++ way is invaluable when reworking large projects while wanting some hope of retaining confidence in the result. 

> It is a bit rude of PyGtk to segfault rather than to fail gracefully, but that's not a gtk-osx problem. Go bug them.

Ah - thanks, no that's all I need to know. 

And, yes that's a rather nasty surprise for someone who isn't in the know (where is the best place to pick this sort of thing up - the gtk lists? I must admit I didn't read the release notes). It's also a bit odd that the idiom is still available if it's effectively useless (i.e. can't read or write via foo.props.bar). None of which, of course, is a gtk-osx issue. 


cheers, 
Richard.