mudlet-makers team mailing list archive

[Lynara Le'dominae <lynarasys@xxxxxxxxx>]

Oh yes, forgot that point:
• getStopWatchTime and resetStopWatch seem to be completely identical in
this implementation, suggesting that either one is incorrectly implemented,
or one is redundant, neither of which are 'good' things.


On Fri, Jan 25, 2013 at 4:06 AM, Eric Wallace <1104487@xxxxxxxxxxxxxxxxxx>wrote:

> Regarding the above reply, whether the current behaviour is consistent
> with the design or not, at least some of it is inconsistent with
> existing documentation, and I think with what most people would expect
> the behaviour to be. My biggest problem in all of this, personally, is
> stopStopWatch. As implemented, it's identical to getStopWatchTime.
> Stopwatches, in the current implementation, cannot really be "stopped",
> and having a redundant function with a name that implies that behaviour,
> and documentation that says that it does, doesn't make much sense.
>
> As far as I can tell, the implementation of stopwatches just doesn't
> really match what one would normally think of as a stopwatch (something
> that can be "can be started, stopped, reset and asked how much time has
> passed since the stop watch has been started", as the API reference puts
> it). Rather, it's essentially just an object that stores some reference
> time, with methods to change that reference time, and return the
> difference between that reference and the current time. As such, there's
> no meaningful way to "stop" it, nor really to render it "inactive".
>
> So perhaps not really a bug, but if the current behaviour is indeed as
> intended, the naming of the functions and the documentation both seem to
> obscure that intent.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1104487
>
> Title:
>   stopwatches have a number of bugs, as listed
>
> Status in Mudlet the MUD client:
>   New
>
> Bug description:
>   • If you createStopWatch, then immediately getStopWatchTime, it has an
> unbelieveably high time - this time should be a stable 0, not an increasing
> time.
>   • stopStopWatch does not actually stop the watch, it only returns the
> current time. This should stop the watch, so that the stopwatch can be
> restarted from the time it was stopped at.
>   • startStopWatch always resets it to 0, instead of just starting it
> where it was left off before. This is a moot point until stopStopWatch is
> fixed
>   • resetStopWatch() should reset the stopwatch to 0, not to the
> increasingly high number it was showing when createStopWatch was called.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1104487/+subscriptions
>

-- 
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1104487

Title:
  stopwatches have a number of bugs, as listed

Status in Mudlet the MUD client:
  New

Bug description:
  • If you createStopWatch, then immediately getStopWatchTime, it has an unbelieveably high time - this time should be a stable 0, not an increasing time. 
  • stopStopWatch does not actually stop the watch, it only returns the current time. This should stop the watch, so that the stopwatch can be restarted from the time it was stopped at.
  • startStopWatch always resets it to 0, instead of just starting it where it was left off before. This is a moot point until stopStopWatch is fixed
  • resetStopWatch() should reset the stopwatch to 0, not to the increasingly high number it was showing when createStopWatch was called.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1104487/+subscriptions