Hey Koen,
On Tue, Mar 16, 2010 at 2:01 PM, Koen Deforche <[email protected]> wrote:
> Hey all,
>
> >> Quite frankly, coming from a user, WTimer should *only* be used with a
> >> session as it is the Javascript (meta-refresh?) interface, just as you
> >> would not use WText without a session (it is the <span> interface) or
> >> WTable, they are all client-side links.
> >
> > Why should it *only* be used from a session? No, sust because you say so
> is
> > not a valid technical argument.
> > I challenge you to provide properly substantiated grounds for you opinion
> on
> > this matter if you can.
>
> The truth is, yes, currently WTimer requires a session because in fact
> it is the browser that waits for the suggested time before issuing a
> new request. In this way, you can properly modify the widget tree from
> within the timeout method and expect changes to be propagated to the
> browser. WTimer thus creates the illusion that you can push changes to
> the browser without actual server push (and it is indeed an
> alternative to server push).
>
>
Well IMHO the class is obviously misnamed. But I understand that it is
too late to change the name now.
> You are right that nothing in the interface suggests this, and
> therefore I agree that at least the documentation should clearly state
> this. It is also true that you could implement the same behaviour of
> WTimer when used without a Wt session. But I think that would actually
> open another question: what thread is used to run the WTimer call-back
> method? Is this a thread related to a WServer, and if so, then you do
> not indeed are not silently relying on a Wt session, but then you are
> silently relying on a thread pool of a Wt server instance. Surely, no
> one will be interested in a WTimer that spawns a new separate thread
> for running the call-back method. So, in practical terms, WTimer will
> still have a hidden dependency on another object.
>
And that is perfectly fine as long as that hidden dependency does not
have any negative impact on the utility of the class.
> (Note in Qt, QTimer relies on the completely weird threading/event
> loop hybrid model and you cannot simply use a QTimer from any thread
> and expect it to work either)
>
>
Yes, this might be so. But QTimer does have a clean interface!
It adheres to basic (an not so basic) OO design principles!
Yes QTimer might have an uqly *implementation* but what does that matter
to the users of QTimer?
QTimer obviously properly encapsulates the ugly implementation in a nice
interface.
Why would Wt not do the same? Why would Wt cherish these hidden
dependencies?
Encapsulation is not only about sprinkling around protected and private
keywords
it is about hiding implementation details of classes so that the
implementation might
change while the interface remains unchanged.
In fact using idiomatic C++ would likely entail that a policy class would
allow the
user to select which of the possible implementations to used for a WTimer.
(A sensible default would be a good thing of course.)
> Given this API problem, and the fact that this requires a completely
> different WTimer implementation in addition to the current one
> (increasing binary size on embedded systems), I am not inclined to
> support this.
>
Why can't embedded folks opt-in to this functionality? Is this not what is
currently done for stuff like XML support etc?
>
> If you want to use a timer outside the scope of a Wt session, I
> suggest to look at boost asio's timer support, which has a clear
> interface for defining what threads should be used to run the callback
> function.
>
> > Please try to understand that if a WTimer requires a session to work it
> > should probably
> > be called a WSessionTimer or similar. Is that not OO design 101?
>
> Clarifying the behaviour through documentation seems to me more
> effective than trying to convey this kind of information through a
> name (does a WSessionTimer time the duration of a session?).
>
>
A timer is a known concept.
Obviously, Wt has a peculiar connotation of the the meaning of what a Timer
is.
I present this discussion as proof that only folks who looked at the
implementation
actually knew that Wtimer is not really a timer in the classical sense but
only in a
Wt specific sense.
So while WSessionTimer may not be a good name for the functionality offered,
I claim that neither is WTimer if it does not support classical usage!
> > The point is that neither the interface nor the documentation of many
> these
> > classes state anything about
> > the requirement for a session. The dependency on a session happens to be
> an
> > artifact of the current
> > *implementation*.
>
> Not really so: the dependency is because of its functionality: namely
> to support updates to a widget tree within the scope of a timeout.
> This requires cooperation of the web browser.
>
I am sorry to disagree with you.
But when you invent your own meaning for known concepts it is hard to have
an informed
disscusion. Current WTimer is not a timer like other timers but some special
thing invented by Emweb.
This violates the principle of least surprise because folks expect that Wt
behaves like a typical
UI library (like for example Qt).
Now I know that I really need to read the source of all the
stuff I use because *you* the designer of Wt, do not seem to endorse the
principles of
orthogonal design. This does not reflect well on you.
No problem.
Please kindly consider ways to save folks the time wasted by:
- unclear interfaces
- hidden dependencies
- and misleading documentation
and let us move on.
Cheers,
Maurice
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
