Exceptions in SFML 3 ?

[Hiura]

I really like this discussion, there's so many good points of view. I've my personal opinion for this specific topic but I could agree with the «opponent» idea in some other contexts.

Let me add two things. First, somewhat paraphrasing Laurent's regarding wintertime's last comment: I haven't looked at the source to check your claims but it's very nice to have some code review, thank you! Regarding your general comment (i.e. split the design) I disagree: it's an implementation detail/issue rather than a design issue. The API design should not care about how the implementation is driven to be efficient.

Besides of that, I don't know what the loadFrom* functions do to the object in detail, because they have full access. Again, this might not be an issue with sf::Image specifically, but if we can even avoid the questioning, then it's a benefit I think.

[...]

But that's exactly what I'm pointing out.. The setters and getters modify/give access to the data itself, which makes perfect sense. For example, calling setPixel() or getPixel() on sf::Image is correct. load*() is completely different, it's functionality that has nothing to do with the data itself. It's an operation that does some random stuff to create/initialize an image. The image itself however does not care about that at all, it's unrelated.

You're describing a Model-Controller(-View) pattern. In some specific case it's very useful, agreed. But here it would just mean breaking – or at least coming close to breaking – the encapsulation. The bottom line with such design is that the Model has some setData(...) method which does some validation check if needed and the Controller use that to set up the model object. Often the model and the controller are so interacted/intricate that having their two interfaces work together cost (to develop/use/...) more than having one class.

Instead it's better to reduce the interface «area» (and thus reduce the issue of interface communication) and mix both Model and Controller (sometimes also the view) to hide the data.

[Tank]

But given its core functionality, it would rather be strange to extract it from the core (sf::Image) to a separate class, wouldn't it?

I have to admit that I haven't checked the sources like wintertime did, but considering that Laurent has already split them up (I don't know when) tells me that it was indeed a positive move. Even if »only« for moving the bulk of unrelated loading code to another place (in my opinion pure design decisions are very important, because the result is what you, as a programmer, have to use all the time). The difference between my attitude and Laurent's is probably that I'd even split it if the external library only needed 2 lines of code instead of the walls it requires right now. ;-)

The loading functions are clearly specific to the respective resource classes, you can't have a generic loader in SFML.

I think loading something can be divided into a source, a driver and the data. Source can be the STL with its streams, the driver has to be custom, just like the data itself.

As mentioned previously, a separate class would also require full access through friendship, unless you add a constructor/method to initialize an image -- but then the API is again inconsistent, because some initializations require a factory and some don't. And again, this is only a superficial design issue, not a real problem.

If the separate class required full access, then it's in no way better than adding the code directly to the class itself. I'm sure that one can think of a nice interface to manipulate the image directly -- or even add a fitting ctor. I don't understand how the API is becoming inconsistent then. It's indeed a problem, not a big one, but real enough to make me think about it. ;-)

Maybe you overlooked my post before, but I'd really be interested in concrete advantages of a separate ImageAdapter class that would justify the drawbacks (more complicated API and implementation, more boilerplate code to write, maintain and debug). What does the user effectively gain from such a modification?

No I've read it, and I've already given some examples + arguments why I think it's better. To me the API wouldn't be more complicated, it would feel more intuitive to me. That's why I'm fine with added »boilerplate« code too. And if SFML used unit tests, the debugging/maintenance part would be minimized too. ;-)

I think we've discussed it well enough. You've got your point of view on this which I partly even agree with. For me the current design is alright, there is definitely no show-stopper, just room to improve in my eyes, or let's say: for my taste.

No, I only use my own creations (previously the Thor logo)

Oh, sorry, I must have connected the logo to your name then. ;-)

if experience has shown that some theoretical idea might not work out in real life then there is no point trying to force people to reduce their productivity just so that something is "theoretically" more clean.

I fully agree, however before declaring something as being counter-productive, that has to be proven as well. There's always theory before practice, and experience alone does not justify ignoring new/different ideas.

[Nexus]

It's interesting that there is already an internal split that nobody noticed. A good example where implementation details are hidden from the user

I fully agree, however before declaring something as being counter-productive, that has to be proven as well.

That's not how it works in practice however; for something new to replace something existing, its advantage has to be proven. Even more, the advantage has to be big enough to justify throwing away existing approaches. That's also why interesting languages like Haskell and D struggle hard to get recognition, even if they do some things better. Of course changing the SFML API is a completely different scale, but it would still come with a lot of effort on implementation and user side. And in my opinion, this effort is worthwhile (mostly) iff the usability is improved. Now this shifts the problem to discussing about usability

Thanks for the elaboration, Tank. I think you're right, we know each other's opinion meanwhile