Re: Runtime optional interface
On Wed, 29 Aug 2007 18:26:23 -0400, Victor Bazarov wrote:
So, what you're saying is that on a different system
(the one without a WM, for instance) it would be a
_different_ Screen class, right? Then it would be a
different application, no?
The system having WM could be used with or without WM.
The system not having WM could be used only the second way.
I think it doesn't necessary have to be one Screen class,
the optional functionality could be dissected into separate
class, like in my second idea mentioned earier
[WindowManager class].
screen.getWindowManager().toggleFullScreen();
//getWindowManager() will throw when the WM isn't available,
//so the toggleFullScreen() will never be called.
I believe you're still confused.
Your belief is right ;) But, like I've said, it's the best
solution up to now.
For this code to compile, the 'toggleFullScreen' member
has to be present in the manager
And it could be. The WindowManager class could do that.
so the code is _compileable_. IOW, your 'screen' will have
to have 'getWindowManager' member function which will
*pretend* to return some WM (say, by reference), but
instead it will throw. Now, is it not cheating the user?
Hmm... Yes, looks like it's not the best idea :/
WindowManager& wm = screenWithoutWM.getWindowManager();
//screenWithoutWM: "What?! I don't have any WM and I don't
//even know what it is! What do you want from me?" :P
I thought you're after some kind of system in which at
_compile-time_ the user cannot even write an expression
like that...
It's something in the middle :| On one hand the user doesn't
know at compile time if the WM is available, so he has to
figure it out at runtime - ask if it's available and then use.
But on the other hand he shouldn't be able to use it if it
isn't available at runtime. He have to ask first, before use,
and this should be required by the code design itself, not
by some documentation which noone reads carefully or
remember ;-J
Still it's not the Holly Grail i'm searching, but at this
moment it's the best solution.
How is this "the best"? The user will get an exception, and it
will say something like "attempt to get a window manager on
a system that doesn't have any". So the user will *still* have
to have a way to prevent that from happening, e.g. by calling
some member like
if (screen.hasWindowManager()) {
// do the "optional" stuff
}
otherwise there is no way for the user to prevent the exceptions
from being thrown.
Yes of course. But this time if he forget to do this, he
won't be able to proceed as if nothing was happened - he'll
receive an exception and if he doesn't handle it, the program
won't proceed to use unavailable WindowManager object.
In the previous example [with returning an error or null pointer]
the user was able to ignore it [by mistake] and proceed to use
invalid pointer or non-existent WindowManager object.
So, it's not the best idea, but better than the previous one
I think.
So, now you're back to plain old polymorphism where your
'screen' implementation can either have or not have a
Window Manager, who in turn can either have or not have
a full screen capability, and so forth. Why do you keep
insisting on some other way? Why does not polymorphism
work for you?
Because I don't see polymorphism here :/
If it were plain polymorphism, the user could use the Screen
class the same way, no matter if WM is available or not,
because the implementation would handle it. But the user
have to have access to that additional functionality if
it's available, which is impossible when accessing it by
the base class [it doesn't understand the optional messages
concerning swithing to fullscreen or manipulating window].
Or maybe there IS some way to access it through base class
with use of polymorphism?
I think rather about some separate class to manipulate
that windowing stuff, but related some way to the Screen
class. But I don't know a good way to access it only
when it is available at runtime.
The important thing is here that if the WM is available
at runtime, this fact is known even before main() is called,
and the WM is available all the time the program run.
--
SasQ