[wxruby-users] wxruby 1.9.9 menu - strange corruption

[Alex Fenton]

Hi Ridge/Mario

Just read through the discussion, and think you're both making sense. 
Ridge, the OO philosophy which you describe is that which I've had in 
mind developing wxRuby, and I believe we already follow in large part.

This is just an implementation issue of an unforeseen use case for a 
particular class, which hopefully we've resolved for the next release.


Ridge Mcghee wrote:
>> What Alex was trying to explain here, is that some classes, such as 
>> Menu,
>> MenuItem, Rect, Point, and various other ones, are considered 
>> Information
>> Classes.  Information classes only hold the information of what is 
>> relevent
>> at the point and time of the execution of the code.  To make it a bit 
>> more
>> clearer to understand, let's take the problem of MenuItem.  Imagine that
>> MenuItem is a Ruby Struct class.

Just to add to Mario's comment - indeed Size/Rect/Point are always going 
to be 'info' classes and not have information added to them. This is 
probably clearer if you think of how they work

window.size = Size.new(100, 50)
# user uses application, including resizing window to 200 x 600
size = window.size
# Size is now [200, 600]

In this case it's a moot point whether it's the 'same' size object, as 
its properties (size, width) are inherent to its identity. And in 
reality, wxWidgets doesn't think it is, so we couldn't return a same 
MySize object in Ruby.

I think the need arises where one could sensibly want to add member data 
(ie instance variables) in a subclass. Your example demonstrated this 
for MenuItem, and I think it's already covered for other classes. 
Indeed, I went through hoops to get this working right for some 
difficult cases (eg custom Event objects).

> Class instantiations should maintain their existence and identity
> until they move out of scope or until they are expressly deleted.
>   

Yep, so far as the tools we have available (wxWidgets, Ruby's GC API, 
SWIG etc) permit.

>>>   Is this a generic ruby issue (or is it unique to wxruby)?

It's an issue which any Ruby C extension library faces: how to make 
C/C++'s explicit alloc/free memory management interact smoothly with 
Ruby's GC, whilst supporting Ruby's highly dynamic OO scheme. It's a 
particularly acute problem for long-running (eg GUI or server) libraries.

As an aside, it's also one reason that Ruby itself is a difficult 
language to implement efficiently - see the initial slowness of most 
early implementations.

>>   What triggers the GC ?

Ruby's GC runs whenever the size of allocated objects has reached a 
certain maximum heap size, and ruby is asked to allocate a new object. 
So from a programmer's point of view, it's not determined, although 
GC.start can be used to invoke GC explicitly.

> At this point, I'm concerned that I will find other
> instances in which the GC will impede my development
> progress.  But I hoping this will not be the case.  It
> may be that the problem is limited to menu items and
> that the GC works beautifully in all other cases. 

I believe this is the case. As Mario's mentioned, there are other 
classes which work like MenuItem (currently) works but I don't think 
they will impede your progress. Although technically a 'beta' release, 
1.9.9 has a few years history behind it, and is one of the most 
widely-used GUI libraries.

alex