Make Transform extensible with "protected"

[criptych]

I propose changing the "private" in sf::Transform to "protected":  this would let users extend Transform to access the matrix data for specialized purposes (3D, color effects, etc.), but shouldn't break the library's internal uses of it.

[Nexus]

We recently discussed the utility of sf::Transform for 3D: See here. And making variables protected is not really the way to go; it exposes implementation details and implies that the class is designed for inheritance, which it is not.

What do you need it for?

[criptych]

We recently discussed the utility of sf::Transform for 3D: See here.

As far as I knew, you (collectively) wanted to leave that discussion to the Shader topic and start a new one for Transform.  It just took me a while to remember that and do it. 

And making variables protected is not really the way to go; it exposes implementation details and implies that the class is designed for inheritance, which it is not.

Well, the idea was that it's a header-only change, so it should still work with existing SOs/DLLs (unless you have a really funky compiler, I suppose).  Long-term, I think a new constructor/setter would be preferable.

What do you need it for?

The short version:  for 3D, of course.  But! before that turns you off to the idea, hear me out.

Yes, I know SFML is designed for 2D, and does a great job at it.  As it stands, however, with a few changes it could "support" (i.e. provide the means to use) 3D without fully having to "support" (i.e. provide library code for) it.  I'm just talking about a little more user control over what goes on; the majority of the graphics module shouldn't even need to change. 

The problem I find is that classes like Transform and View are integral parts of the pipeline to RenderTarget, but they're closed off to the point that you can't really hook into that pipeline.  They (especially Transform) could be modified to keep their normal behavior by default, preserving backward compatibility, but also let the user fine-tune them as needed.  (Using direct OpenGL calls is a possibility, but that has its own pitfalls interacting with a framework. )

I'm open to hearing other ideas, but I saw this as the "simple" solution.

[wintertime]

Yeah, SFML is very nice for 2D and its also possible to use only some of its subsystems, but at some places inside a subsystem its made so airtight that its near impossible to find a good hook for extending without doing everything yourself.
In your place I would just use glm for all calculations and then find a way to use your matrix, even if you need to use OpenGL calls after creating the Window or RenderTexture, because for 3D you need OpenGL anyways. You may need some calls to setActive or reset/push/popGLstates, if you want to keep doing some 2D drawing through SFML, but that should be no real problem for you.

[Nexus]

When working in 3D, one usually has a separate framework/engine that does all the graphics, or at least a self-written abstraction on top of OpenGL or DirectX. When making sf::Transform more accessible, you would just manually add the 3D functionality, that another library for 3D graphics or linear algebra already provides.