.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/7ec2c071-9630-42b0-b08a-9854616f9144/comments/ec133a4e-c9ff-4499-b469-cb0a2ca9a685/body

   1 In Aaron's Tue, 25 Nov 2008 09:32:29 -0500 email:
   2
   3 >> 7ec:om: Arbitrary tags
   4 >> Sensible
   5 >
   6 > Implemented as a free-form value field similar to target?  A
   7 > comma-seperated list of tags?
   8
   9 I believe I planned to store it as an alpha-sorted, one-entry-per-line
  10 list, so it would support merging easily.
  11
  12 >  Perhaps once we have per-bug/comment
  13 > attribute searching it would be easier to have a 'create-attribute'
  14 > becommand, e.g.
  15 >   be create-attribute [-valid=X,Y,Z] [bugdir|bug|comment] [NAME] [DEFAULT]
  16
  17 Well, it really depends how much semantics you want to embed in the data
  18 format.  Some values are scalars, some may be sets (i.e. tags), some may
  19 be ordered lists or even mappings.  How much you want to reflect that in
  20 the data format is up to you.
  21
  22 > Extend and make more consitent the settings_property() attributes.
  23 > Create becommand/(create/remove)-attribute for logic-less attributes.
  24 > Create a few mix-ins for logic-ed attributes
  25
  26 I don't find the term mix-in very intuitive here.
  27
  28 > Usage example:
  29 >   Goal:
  30 >     set up for `be depends BUGA BUGB`, `be depends --tree BUGA`, etc
  31 >   Procedure:
  32 >     be set --apend mixins bug:dependency
  33
  34 "append" usually has two "p"s.  Is the omission deliberate?
  35
  36 >   Where we've defined
  37 >     becommands/depends.py, but it is hidden until the mixin is activated
  38 >     libbe/mixins/bug/dependency.Mixin (inheriting from BugMixin)
  39 >       to
  40 >       parse/generate comma seperated dependency uuids for saving/loading
  41 >       pretty-print the dependency list (e.g. uuid->shortname)
  42 >       walk the dependency tree and check target bug status.
  43 >
  44 > With more complicated mixins, there could be inter-mixin dependencies,
  45 > e.g. a dependency tracker that searches depends based on bug.status
  46 > might depend on the base dependency mixin.  This way people who need
  47 > it could make rich interfaces without confusing the people who don't.
  48 >
  49 > How does that sound?
  50
  51 It sounds pretty complicated.  I would probably use a type system rather
  52 than "mixins", and define types as "scalar", "set" and maybe "list" and
  53 "map".  Dependencies would be a set, and their special behaviour would
  54 be hardcoded according to their name, not a property of their type.
  55