1. 13:49 <RAOF> What do you think of pulling the age() related bits into ClientBuffer; the implementation shouldn't be different between AndroidClientBuffer and GBMClientBuffer.
  2. 13:49 -!- schwejk3 [[email protected]] has joined #ubuntu-mir
  3. 13:51 <RAOF> I'm leary of mixing interface and implementation there.
  4. 13:51 -!- schwejk2 [[email protected]] has quit [Ping timeout: 252 seconds]
  6. 14:51 <racarr> RAOF: I kind of like pulling the age related bits in...(just catching backscroll)
  7. 14:51 <racarr> the mixing implementation and interface is a red flag though
  8. 14:51 <racarr> the other red flag is the
  9. 14:51 <racarr> implementation of the ageing semantics on the mock buffer with the expectations
  10. 14:51 <racarr> in one of the tests
  11. 14:51 <RAOF> Yeah, that's rather awkward.
  12. 14:51 <racarr> which says that really there is
  13. 14:51 <racarr> another object
  14. 14:51 <racarr> BufferAgeTracker (complete strawman name)
  15. 14:51 <racarr> and its an integration test
  16. 14:51 <racarr> but...eh
  17. 14:52 <racarr> I am not sure how strongly I feel about it
  18. 14:52 <duflu> racarr: Orange flag at most. If there's no real testing value gained by mocking systems code then I think it's often OK to mix implementation with interface
  19. 14:52 <racarr> Sure, orange flag :)
  20. 14:53 <racarr> Maybe Buffer has a member
  21. 14:53 <racarr> type BufferAge
  22. 14:54 <RAOF> ClientBuffer could well have a public uint32_t age, yes.
  23. 14:54 <duflu> On the other hand... being able to test code natively is preferable to mocking. And if you can do that, then you don't need to separate interface from implementation
  24. 14:54 <racarr> RAOF: No I mean a
  25. 14:54 <racarr> BufferAge age, and then the methods increment_age, mark_as_submitted, age()
  26. 14:54 <racarr> etc
  27. 14:54 <racarr> move to BufferAge definition
  28. 14:54 <racarr> and out of the platform code
  29. 14:55 <RAOF> Possibly. I *think* the Buffer might actually want to do something on mark_as_submitted(), though.
  30. 14:55 <racarr> duflu: Here the interface is seperated because it actually has multiple implementations
  31. 14:55 * duflu stops generalizing about code he hasn't seen yet
  32. 14:56 <racarr> RAOF: does it have to do with the age
  33. 14:56 <racarr> duflu: Hehe. my number 1 hobby!
  34. 14:56 <RAOF> racarr: No, not to do with age.
  35. 14:56 <racarr> RAOF: Then I would imagine
  36. 14:56 <duflu> Generally speaking... we should use Go.
  37. 14:56 <racarr> buffer.submit() does that thing and
  38. 14:56 <racarr> also calls buffer_age.mark_as_submitted()
  39. 14:56 <RAOF> racarr: The *age* interface doesn't actually have multiple implementations, though.
  40. 14:57 <racarr> RAOF: In what tense? Right now it does i.e. increment_age is implemented in the test, the android buffer and the gbm buffer
  41. 14:58 <racarr> so the idea is to just move the implementation to a single shared BufferAge type
  42. 14:58 <RAOF> racarr: In the sense that it's ever sensible to have different behaviour there.
  43. 14:58 <racarr> mm
  44. 14:58 <racarr> so I mean it's a concrete type
  45. 14:58 <racarr> its just to avoid mixing implementation in to the ClientBuffer API
  46. 14:59 <racarr> I guess there is still some :)
  47. 14:59 <RAOF> Alternatively, ClientBuffer abstract, AgeableBuffer concrete, {GBM,Android}ClientBuffer inherits from both?
  48. 15:00 <racarr> RAOF: Mm
  49. 15:01 <racarr> RAOF: Anyway...I don't feel strongly enough about any of these to feel like
  50. 15:01 <racarr> blocking on it...but maybe if you think one is a particularly good idea or europe has a good idea :)