[Kde-games-devel] KGame/KPlayer API usability in kdegames

[Dmitry Suzdalev]

> Why hack? It's the correct solution to a situation where a predefined class
> can't be used.
Yes, but when the class usage becomes not evident and I have to place
a workarounds like this here and there, I call it a hack.
In my terminology at least :).

> I have no idea what you are talking about.
That's because I didn't go into details. Don't know whether you're
interested, but to be brief:

to emulate signalMouseEvent(KGameIO*, QDataStream&, QMouseEvent*, bool*)
from QGraphicsView::mouse*Event() i need KGameIO* and QDataStream.
And there's no way to know something about KGameIO* object within that
QGraphicsView-derived class because KGameIO* is created and maintained
internally by KWin4Doc class...

> I don't see what's hard to understand here. You simply use the streams
> provided by the signal to communicate.
Well, I'll try to explain.

I had a hard time understanding a fact that when I change some
parameter (QDataStream&) in slot it 'magically' influences futher
program behaviour.
In my day-to-day programming I rarely encounter a slots which modify
their parameters and rely on that change.
It's the same as functions with non-const references as a parameters -
I find them misleading.
I.e. instead of writing

void func(A& a, B& b, C& c) {}

I'd rather implement something like

struct ABC
{
   A a;
   B b;
   C c;
};

ABC func(const ABC& abc) {}

I feel that this is more straightforward, more pretty looking, more
programmer friendly.
That's my feeling anyway.
And because of that feeling, personally, I don't like that slots with
QDataStreams& - I feel they are not-so-obvious.
IMHO.

Dmitry.