Am 09.09.2013 20:47, schrieb Robert Osfield:
On 9 September 2013 18:30, Sebastian Messerschmidt
<[email protected]
<mailto:[email protected]>> wrote:
Am 09.09.2013 19:58, schrieb Robert Osfield:
Hi Sebastian,
On 9 September 2013 17:34, Sebastian Messerschmidt
<[email protected]
<mailto:[email protected]>> wrote:
No offense, but this feels more like a hack than my solution.
Indeed, but it's hacks that external to the core OSG done for a
very specific end user purpose, rather than hacks in the core OSG
for a very specific end user purpose. The OSG has many users and
many different usage models, internalizing all these usage models
is in-inappropriate. Would you have me merge every little whim of
the community or only should I be beholden to just your whims?
Or should I try to make sure that any core modifications are
fully justified?
I surely don't want to argue with you, but I simple do not see
where it hacks the core. I somehow feel that it simply breaks the
rules of deferring it to a callback.
Perhaps you should review the code if you don't think it's a hack...
It's a crazy partial disabling of an existing behaviour. It only
makes sense in the context of what you are doing, other users coming
along won't realize what the code is there for and how it's intended
to be used. It's only once you add the magic of what you are doing in
your application that it can make sense, even then it's not quite
sensible.
I'll do that.
The point is, that the original solution simply does not move any
information to the outside. I agree that is not the cleanest
solution to open up multiple code paths here.
What I don't get is the initial design. In my understanding it is
bad design not to call the original implementation (i.e.
findFile), as a user adding callbacks will fail. So chain of
responsibility is broken here.
One could have the OpenFlight plugin defer to finding files to the
image plugins, some plugins do this - for instance native OSG formats
simply do a readImageFile() without forcing the find path. Changing
OpenFlight across to not doing it's own findDataFile() would
potentially break user code though if an image plugin doesn't both
doing a findDataFile(). If one was to make something optional that it
would be the findDataFile() call, it wouldn't be the ignoring the
result of the file call.
So we agree. It should defer it, but it doesn't. I don't get the
last part however. Can you elaborate how it would break?
Any change in behaviour has the potential for breaking existing users
applications, changing something as fundamental as the find behaviour
is something that clearly could have repercussions to end user
application code.
My solution takes care of making the new, in my eyes preferred
way, optional in order not break user code.
Forget your solution. It's a hack and rejected in it's current form.
Got it :-)
You are right however: Passing the information would solve my
problem since I only need to know which files are missing.
Also I want to point out that I'm not the only person having
this problem.
Having more people wanting a hack to be merged into the core OSG
doesn't change the fact that it's a hack. We can and should do
better where we can.
You are right. I simply don't feel very comfortably with the
"FILE_NOT_FOUND:filename" solution. But maybe we can raise this to
a higher level to make it cleaner.
I'm open to suggestions, but I'm still not convinced that the
presented solution is evil ;-)
It's isn't evil, but it is bad programming solution. I want to see
the code base improving over time not steadily going downhill.
A question: In terms of following the unwritten rules - attaching
callbacks is meant to defer resolution of such errors to the user.
The plugin handles this in a very strange way. So the presented
solution makes it more the way it was intended.
The plugin isn't really behaving that strangely, it searches for a
find and if it can't find it it doesn't attempt to load it.
The only thing missing is that you want to do something extra which is
not the usual usage model. The implementation isn't only strange when
viewed from your application specific needs.
Right?
Then we could use the callback pattern over the current
implantation and make the old behavior optional and see how many
people's code it is actually breaking.;)
Let me know if you can think of a viable solution
Having an option to disabling the local findDataFile() calls and
instead relying upon the image plugins to handle the find is something
that I'd be open to do. Making it the default is not something that
feel comfortable with at this point. We'd have to do big call for
testing from OpenFlight users to find out whether this change of
behaviour would introduce any regressions.
Okay. So if I understood this correctly, it would be much cleaner if I
move the code inside the findDataFile and provide an option to enable
deferring the find to the image plugins.
I'll rethink the solution and re-submit it. Maybe we will need one or
two iterations to improve functionality while preserving code quality.
P.S. I don't take any of this personally. I really appreciate your
effort of keeping the code clean and yet extensible.
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
