freenode/#shirakumo - IRC Chatlog
Search
8:59:06
Shinmera
mostly because changes in the data representation need to be observable, so there has to be a way to call back.
10:48:52
Shinmera
A slider has a value, a range, and a step. Are the range and step part of the data, or part of the representation?
10:52:49
Shinmera
Yeah, it /is/ kinda both. or rather, I suppose the value is.. the value, and the rest are type attributes of that value.
10:53:52
Shinmera
I'm asking because of the now duality of information in Alloy; the representation (component) and the data it represents.
10:54:23
Shinmera
I think for the slider I'll keep the range and step on the component, since that means there's less of a protocol to implement for the provider of the represented data object.
10:55:15
|3b|
yeah, might want the ability to have them separate even if you do have a 'data' version
10:55:40
|3b|
like you might want a control that has a limited range even if the data allows wider range
10:57:00
Shinmera
I mean, the user could still do that if there was a protocol for it, it would just be more of a hassle.
10:57:25
Shinmera
If you really need that tie-in I suppose you could always subclass the component and redirect the methods yourself.
10:57:54
|3b|
you might also have multiple 'step' values, for example used with shift/ctrl/whatever modifiers
10:59:16
Shinmera
Alloy has a float for the scroll event distance already, so I got that base covered :)
11:00:44
|3b|
not sure if it is a meaningful idea, but if you have a minimum 'step', like the value must be even integer or something
11:01:36
|3b|
though possibly that would be on the data side, and it could just have a filter function if it needs something special like that