Connect slot to an int function !?

[nroberts]

The point is to have the encapsulation in the first place.

Sigh...this is bad. Really bad. Just applying encapsulation willy-nilly is just not the way to do things. I shouldn't have to convince an "expert" of this fact but I suppose anyone stepping into your trap will figure it out quickly enough.

And it is you who should be blushing if you suggest using an external signal mapper object as a good design. Read your own posts again and ask yourself whether an external signal mapper object is not a dependency here and is it the right encapsulation type and also think about all the other stuff you have written. It's nice that you know the rules but you are violating them yourself.

I actually supplied a lot of reasoned explanation and all you say is, "You're violating them." You'll need to point out HOW or I'm just not buying.

You ask, is using an external mapper a good design?

I explained quite clearly that it depends and that at this point, given what I know of the OP's requirements...YES! But lets say I'm totally wrong about what the user needs and in fact they really do wish to directly map particular UI elements to indexes in their model (as in they seriously wish to couple the model's index to particular UI elements and there is no other way to index whatever they're tracking). Would I change my story?

Answer: NO! Why? One word: composition. The fact that mapping from one thing to another is a specific and unique responsibility has not changed. Put that stuff into an object responsible for just that and then USE that object within the object you want to couple it to.

You ask whether an external signal mapper object is not a dependency here.

Well, unless you can show me where I'm wrong my answer is a very certain NO! Why? Because NONE of the objects in question depend upon it!

Does the set_m(int) object depend on it? No. Anything that calls set_m with an integer is a valid client.

Does the object sending the signal depend on it? NO! It can be connected to anything which can observe the signals it emits.

Does the mapper itself depend on either the signal generator or the set_m(int) object? No! It can be connected as a receiver to any object and then emit a signal to any object upon which that mapping is useful.

Does the set_m(int) object depend on the button or UI element that generates the original signal? No! It doesn't care who requests an index change. Only if it's done your way to we see coupling in this direction.

Does the button depend on the set_m(int) object? No. It just pops signals to anyone that will listen.

So no, I don't see any unnecessary coupling or dependencies here. Most of the objects don't even know that the others exist and don't even care.

There are only two entities that depend on the mapping: the mapper itself and the code that created it. In this case, since we're not recommending a more complex but open design that uses a mapper interface and factory, this later part is the function that connected the three objects together. This is a very small, localized part of code that is hopelessly coupled because it simply HAS to be.

...snip a bunch of "should" "should" "should" without any reasoning behind it... <- it's all rather beside the point anyway (and please use some semblance of paragraph structure!)

I say that the sole fact of using a signal mapper doesn't really solve the problem especially since I pointed out a situation where it fails completely when used as an external object hence making the whole "architecture" completely unreliable and unreusable in an Open World.

You'll have to point out where you showed it wouldn't work because I not only missed it the first time but can't find it when I try to backtrack. In fact, I can only see where you claimed it didn't matter.

I don't know who "Daniel" is, but if it's "high_flyer" then I really suggest you reevaluate his proposed solution. It's not even valid C++, as has been pointed out already.