Timeline for Is there a hashCode()-like method that can be used for state checking?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 4, 2015 at 1:56 | comment | added | candied_orange | @LinkTheProgrammer how passive is passive? The observer pattern is flexible enough to let you dump a reference to every updated object in a queue that you can process (inspect state) whenever you like, as passively as you like. Thus avoiding iterating over things that haven't changed. When you process and when you clear the queue are completely decoupled from when state changes. If, rather than passive, you decide to be aggressive about clearing the queue, look into the producer consumer pattern. | |
| Jun 4, 2015 at 1:09 | comment | added | AMDG | @CandiedOrange I want to be able to check for the state of an object at any arbitrary time. Not notify an observer when the state changes. The effect should be passive. | |
| Jun 4, 2015 at 0:58 | comment | added | AMDG | @CandiedOrange Because that isn't the purpose of this implementation. The State implementation doesn't have to be event based. And that could cause a lot of overhead if it notifies a List of Observers every tick. | |
| Jun 3, 2015 at 2:25 | comment | added | candied_orange | @LinkTheProgrammer Then help me understand, why bother recalculating hashcodes when properly encapsulated classes could simply notify their observers when something changes their state? | |
| Jun 3, 2015 at 2:22 | comment | added | AMDG | @CandiedOrange why, of course :) | |
| Jun 3, 2015 at 1:05 | comment | added | candied_orange | @LinkTheProgrammer before you give up on avoiding iteration let me ask, do you know how the observer pattern works? | |
| Jun 2, 2015 at 18:05 | comment | added | Persixty | I have no idea what you're trying to do. Minecraft avoids some comprehensive iteration by making some events random so it can sample. | |
| Jun 2, 2015 at 17:21 | comment | added | AMDG | I'm starting to think avoiding iteration is futile. | |
| Jun 2, 2015 at 17:03 | comment | added | Persixty | I would help if you told us more about what you're trying to implement. I would say most real time applications end up needing to notify some monitor that they've changed rather than wait for a recurring laborious sweep. | |
| Jun 2, 2015 at 16:52 | comment | added | AMDG | Would it help to say the thing I am creating this for is an API that works for the realtime game Minecraft? | |
| Jun 2, 2015 at 16:50 | comment | added | Persixty | Then this is a scenario where a version counter might apply. | |
| Jun 2, 2015 at 16:38 | comment | added | AMDG | Well, events are on a "last-visit" basis. | |
| Jun 2, 2015 at 16:37 | comment | added | Persixty | Unless you're going to emit a message (to a monitor) when state changes I would say for nanosecond counts of 'did something here just change' then a version counter is indicated (not contra-indicated). It's partly a matter of whether you need to respond to all changes or just know if there were changes since your last visit. | |
| Jun 2, 2015 at 16:31 | comment | added | AMDG | This incrementing based on state change is a good idea for non-realtime programs I would suppose. I would prefer a way to do so on the fly. In my case, every nanosecond counts. And proven by all those problems which can be encountered due to race conditions, that's the last problem I need and overly complex. | |
| Jun 2, 2015 at 16:28 | history | answered | Persixty | CC BY-SA 3.0 |