[Kde-perl] no addItem in Layouts?

[Germain Garand]

Le Dimanche 04 Janvier 2004 06:20, Thomas Fjellstrom a écrit :
> On January 3, 2004 09:29 pm, Ashley Winters wrote:
> > > I tried:
> > > my $spacer = Qt::SpacerItem(1, 1, &Qt::SizePolicy::Maximum,
> > > &Qt::SizePolicy::Maximum);
> > > $ok_box->layout()->addItem($spacer);
> >
> > $ok_box->addItem($spacer);
>
> huh? Why was that done? the Qt docs mention nothing of a addItem method in
> the HBox/VBox widgets, yet is in the base Layout classes... Also didn't see
> any mention of it in the PerlQt docs ;)
>

there seem to be some confusion here... since you did not tell what's inside 
$ok_box, it's hard to know what you mean.

If $ok_box is holding a Qt::Widget and not a Qt::Layout of some kind, then
your code is correct and you've most likely got a polymorphism problem.

PerlQt is not polymorphic strictly speaking, nor is Smoke. When you call 
addItem on an object that claims to be a Qt::Layout, then it will call 
Qt::Layout::addItem
Since Qt::Layout::addItem is a pure virtual, that won't work.

Ordinarily, when PerlQt already knows about an object, it will pre-cast it to 
the most accurate class, so the object you get will be e.g a Qt::GridLayout.
And that will work fine.

But if you get a pointer via Qt to an object that has never been seen before 
on the perl side, 
it will probably be of the lowest common denominator class (here: a 
Qt::Layout)

This problem is alleviated in the upcoming PerlQt by making use of Qt's 
various RTTI mechanisms to pre-cast unknown objects, thanks to Richard Dale's 
work on this.

But in PerlQt < 3.009, if the object has not the most accurate class, you need 
to

CAST( $foo->layout(), "Qt::<the derived layout>")->addItem($bar)

Beware that CAST is reblessing the object to the given class, so it's 
"sticky". Also: no checkings are performed.

This is foreward compatible of course.

> > > I also have another question.. is it possible to access the
> > > attributes of your
> > > own subclasses, from outside those objects, besides through making
> > > your own
> > > accessor methods?
> >
> > If you want to break encapsulation, go for it; it's one of the joys of
> > Perl. The attributes aren't hidden: $your_object->{foo} accesses the
> > 'foo' attribute declared in $your_object's class.
>
> Very nice :) though, now that I think about it.. Its not that "brilliant"
> of an idea... I just hope I never change the name of any accessed
> attributes ;)

did you intend that to be tactful? :-}
If you want to just _get_ the attributes, keeping the compile-time checking, 
then you can write
object->the_attribute->foo()

if you want full get/set access without getters/setters methods, and including 
the "shoot-yourself-in-the-foot" option, then you must indeed use the 
object's hash and suffer the traditional lack of checking on perl objects. 
Isn't that a fair tradeoff?

G.