[Kde-bindings] name conflict between Qt::Widget#raise and Kernel#raise

[Gary Greene]

On Sunday 24 May 2009 09:45:27 am David Palacio wrote:
> On Domingo 24 Mayo 2009 07:35:52 Stefano Crocco escribió:
> > From inside a Qt::Widget, you can't raise an exception using raise,
> > because it's shadowed by Qt::Widget#raise method. For example, take the
> > following code:
> >
> > class W < Qt::Widget
> >
> >   def raise_error
> >     raise RuntimeError, "This is an exception"
> >   end
> >
> > end
> >
> > a = Qt::Application.new []
> > w = W.new
> > w.raise_error
> >
> > What I'd expect, of course, is a RuntimeError raised by the last line of
> > code. Instead, ruby attempts to call Qt::Widget#raise and gives a
> > NoMethodError because Qt::Widget#raise takes no argument.
> >
> > I can solve this problem by calling Kernel.raise instead of simply raise,
> > but I think this is:
> > a) confusing for the user, who might even not be aware that raise is a
> > method and think it a keyword
> > b) undesirable, because I think it's much more common to want to raise an
> > exception than to use Widget#raise.
> >
> > In my opinion, the best course of action would be to rename
> > Qt::Widget#raise to Qt::Widget#raise_widget or Qt::Widget#raise_to_top or
> > something similar, so that Kernel#raise can be freely accessed.
> >
> > Stefano
> > _______________________________________________
> > Kde-bindings mailing list
> > Kde-bindings at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings
>
> That is expected in Ruby's inheritance. And «raise» is not the only method
> overriden in a Qt class (as «exec», «load» and others). Changing this will
> only make QtRuby have many special cases (and break existing code). IMO,
> Kernel.method is the best solution for these rare cases.
>
> And actually, I wouldn't raise an Exception inside a Widget. Instead, I'd
> emit a signal.
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings

I agree with David here.

If you're working on the model, instead of the view, I could see raising an 
exception, however when you're working directly on widgets, you're in the 
view. The UI should never be treated as part of the model, as it is a clear 
violation of the model/view principle.

Classes that raise exceptions should not inherit from Qt::Widget, rather they 
should be either custom worker classes derived from the Ruby hierarchy of 
classes, or inherit from Qt::Object.

-- 
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
 12:20:18 up 20 days,  4:46,  4 users,  load average: 0.57, 0.59, 0.50
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.