RE: [Wxruby-dev] Internal mechanism question

[Curt Hibbs]

Kevin Smith wrote:
>
> I'm just now looking at how WxFrame::GetMenuBar is implemented. It asks
> the cpp object for its menubar, and then constructs a new ruby object to
> wrap it.
>
> One drawback of this approach can be seen in the following case: A user
> creates a Ruby class that subclasses WxMenuBar, creates an object of
> that class, and adds it to their frame. If they call frame.getMenuBar,
> they should get back their same object, which would be of their own
> subclass. With the current implementation, they would not.
>
> The quick proposal I can think of is that every time a WxMenuBar is
> created, we would store the Ruby and cpp objects in a map. Whenever the
> user calls frame.getMenuBar, we would retrieve the cpp menubar, and then
> return the corresponding ruby object from the map. If there were no
> entry, we would create a ruby wrapper object at that point.
>
> Does this sound reasonable? I consider it fairly low priority, but worth
> doing at some point.

Why not have the WxFrame class contain an instance variable that holds a
reference to the frame's menubar (which is initialized to nil). Then when
get_menu_bar is called, the wrapper is created if the instance variable is
nil, otherwise the value of the instance variable is returned.

Curt