View Single Post
  #7   Spotlight this post!  
Unread 15-06-2014, 02:09
SoftwareBug2.0's Avatar
SoftwareBug2.0 SoftwareBug2.0 is offline
Registered User
AKA: Eric
FRC #1425 (Error Code Xero)
Team Role: Mentor
 
Join Date: Aug 2004
Rookie Year: 2004
Location: Tigard, Oregon
Posts: 486
SoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant future
Re: Challenge problem: 'ladder of abstraction' iterative design in FRC

Quote:
Originally Posted by Colby Skeggs View Post
...I can easily make a replaceable timing system, but then built-in timing systems cannot be used (like System.currentTimeMillis(), java.util.Timer, the WPILib Timer, Thread.sleep, Object.wait, and probably a bunch more.)

The key part here is that since I'm writing a large framework for more people to use than just me or others on my team, I want to avoid forcing this kind of change in user programs.
I think not allowing calls to the built-in timing systems is reasonable and a custom "timing system" is not required to replace it. A single way to get the current time is sufficient. Other abstractions can be built on top of that.

I know you've said that you've had your last release of CCRE to break compatibility but how many external users do you have?