Mario S. wrote:
Thanks for joining the discussion. Hopefully, we can have some
Let me explain this a bit further in detail as to the process the
Collector, and wxRuby’s own classes work about things.
On Sun, Jan 4, 2009 at 5:22 PM, Ridge M. email@example.com
to make it a fully-qualified class, huh?) If I understood your
message, the GC is making decisions based on the type (MenuItem).
Isn’t this just what an object-oriented system should not do?
What Alex was trying to explain here, is that some classes, such as
MenuItem, Rect, Point, and various other ones, are considered
Classes. Information classes only hold the information of what is
at the point and time of the execution of the code. To make it a bit
clearer to understand, let’s take the problem of MenuItem. Imagine that
MenuItem is a Ruby Struct class.
Defining it as such:
MenuItem = Struct.new(:title,:id,:parent,:bitmap)
This is a silly mockup of what I’m trying to explain, but this is what
boils down to. Once you actually create the control, there’s no further
need to reference this control, till something happens with it, such as
evt_menu(Wx::ID_OPEN), this is where we re-retrive the actual wxRuby
control, for any association needed to do special things, such as
the title of the Menu item. There is no other things you can really do
a MenuItem, aside from either updating it, or deleting it. Atleast, as
as wxWidgets is concerned. Therefore, if you don’t store the instance
the MenuItem in a variable, where the Garbage Collector can see that it
still being referenced within your code, Ruby thinks that it is no
needed, and therefore frees it up for others to use.
Your explanation is clear and I appreciate your effort to make it so.
I’m hoping I can be as clear.
I understand your perspective but respectfully disagree with your
“There is no other things you can really do with a MenuItem, aside
from either updating it, or deleting it.”
One of the hallmarks and most powerful aspects of an object-oriented
language is that new developers are able to extend the capabilities of
existing classes via subclassing (in ways that the class originators
didn’t necessarily anticipate). By constraining classes in arbitrary
ways (IMHO), that power is severely limited.
I do understand (I think) your desire to free up memory that is not
being used. However, there are already mechanisms in place: scoping
rules and delete. Please help me understand why these mechanisms
are not sufficient in this case.
If you are providing extra GC as a convenience, then I respectfully
submit that the developer should be permitted to accept or reject
that convenience so that his/her code will behave as expected. By
forcing extra GC upon the developer for certain classes that are
considered “information classes” by the originators, the code
(originally attached) behaves in a most unexpected way:
On (approximately) the 25th time a class instance is used (in this
case a menu appears), the (subclassed) menu items suddenly lose
their identity and instead assume the identity of their superclass.
Until I have the opportunity to understand your perspective more
fully, I respectfully assert:
Class instantiations should maintain their existence and identity
until they move out of scope or until they are expressly deleted.
Is this a generic ruby issue (or is it unique to wxruby)?
This is a unique problem with wxRuby. It’s mainly a decision of what we
need to continue to keep tracking, without tracking every single object
I appreciate your candidness. I’m hoping we can find a way for
wxruby to be more ruby-ish.
What triggers the GC ? (While testing, I found that the “rewrapping”
occurred whether or not I called find_item. Just repeatedly
the MyMenuItem, which triggered a menu_event and caused on_menu_event
to be called, would result in the MyMenuItem being “rewrapped” as a
MenuItem. As such, over-riding MyMenu#find_item would not be
to solve the problem.)
Garbage Collection, especially in a wxRuby app, happens quite often, as
there are many times that a Ruby object is temporarly created, to
it with a wxWidget’s object. And 9 times out of 10, it’s a temporary
reference, which is immediately de-referenced within the code, and when
Garbage Collection runs again, it’ll delete this instance. However, in
particular instance of Menu Event (evt_menu), there is no particular
reference to review to say, Oh, this needs to be referenced by previous
I understand your point that object creation is often
temporary and that, with regard to Menu events, there
is some difficulty in knowing what is a temporary
instantiation and what is not.
However, again I respectfully submit that it seems
ill-advised to use probability as a solution without
offering an alternative.
Unfortunately, in this case, the procedure that Alex has referenced,
be the best way, as it would be nearly neigh improbable to track every
single custom class creation, between wxWidgets and wxRuby. As with
wxWidgets, there’s nothing to allow us to track custom classes created
Ruby of wxWidgets classes, least we create a new memory structure, that
would inherit from one of our classes. It may be doable, in the Ruby
at the actual Ruby level itself, but not on the C++ Side.
Thank you for your trying to educate me about wxruby and
for offering work-arounds that I can put in my code.
I am not sure at this point why you seem so concerned about
“tracking every custom class creation” when, in both C++ and
ruby, subclassing is such a fundamental part of the language.
There are already mechanisms available to the developer to
handle memory bloat (scoping rules and express deletion of
I am very happy that you folks are working hard to support
wxruby. wxruby seems to be a comprehensive, cross-platform
GUI toolkit that could meet my needs. I respect your
willingness to discuss issues such as the present one.
I also respect your willingness to explain why you have
made the decisions you have made.
I hope you can also understand my surprise to be faced
with such an unexpected problem on the first day of wxruby
development. I want to believe that there is a solution
that will meet the needs of all developers.
At the risk of sounding bold, would you consider supporting
"wxruby fully supports subclassing, respecting scoping rules
to handle object persistence. However, developers should be
advised that they can unwittingly consume memory resources
if they do not properly manage their objects, specifically
if they do not delete objects when they are no longer needed.
We have learned this through bitter experience.
"Since object management can be a daunting and tedious task
for the developer, wxruby provides a super-cool garbage
collection facility that can automatically delete objects
that are no longer referenced, significantly reducing runtime
memory usage. When creating your application, simply set
supercool_gc to true, as in the following example:
class MyApp < App
@supercool_gc = true
"The following classes are considered ‘information classes’
and will be specifically targeted by the GC:
“If you subclass any of the information classes, please
note that you may need to disable supercool_gc for
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. In
that case, developers would want to take advantage of
the GC and would alternatively perfer to have a specific
@supercool_menuitem_gc flag so that they could manage
their menuitems independently but have the GC manage
the rest of the objects. Or, perhaps there should be a
flag for each “information class”. I’m hoping we can
sort this out.
As noted, since I’m a wxruby newbie, I welcome further
explanations to help me understand why the GC must behave
as it does. I would very much like wxruby to succeed.