https://pantsbuild.org/ logo
Powered by
#development
  • w

    witty-crayon-22786

    02/01/2017, 8:37 PM
    ?
  • w

    witty-crayon-22786

    02/01/2017, 9:16 PM
    (i think i figured it out... posting a review shortly)
  • w

    witty-crayon-22786

    02/01/2017, 9:16 PM
    but still interested
  • f

    fancy-queen-20734

    02/01/2017, 9:16 PM
    Ah, so I hadn’t dived deep into enum patterns yet. Initially I’d had datastructures containing boxed trait implementors. The current impl avoids that, but at the cost of having a overloaded notion of what an entry is.
  • w

    witty-crayon-22786

    02/01/2017, 9:17 PM
    yep. comment incoming.
  • f

    fancy-queen-20734

    02/01/2017, 9:17 PM
    After looking at selectors more closely, I think I could flip it so that entry type contains the structs instead
  • w

    witty-crayon-22786

    02/01/2017, 9:17 PM
    i think it should just be one big enum
  • f

    fancy-queen-20734

    02/01/2017, 9:17 PM
    yeah
  • w

    witty-crayon-22786

    02/01/2017, 9:17 PM
    @fancy-queen-20734 : there is one question there
  • f

    fancy-queen-20734

    02/01/2017, 9:17 PM
    I agree. My main focus last night was to get it in a state were it worked and then make it more idiomatic
  • w

    witty-crayon-22786

    02/01/2017, 9:17 PM
    which is whether you ever need to be able to hold, say, a 
    Entry::Root
    independently
  • w

    witty-crayon-22786

    02/01/2017, 9:18 PM
    if you don't, then you can just make the variant in the 
    enum
    itself a struct... rather that declaring a separate struct
  • f

    fancy-queen-20734

    02/01/2017, 9:18 PM
    I don’t per se, but being able to do that is handy for the RuleGraph structure so I can have type checking on the contents of the different lookup tables
  • f

    fancy-queen-20734

    02/01/2017, 9:18 PM
    which I’m emulating via checking flags
  • w

    witty-crayon-22786

    02/01/2017, 9:18 PM
    true
  • w

    witty-crayon-22786

    02/01/2017, 9:18 PM
    it's also possible to do on an enum-by-enum basis.
  • f

    fancy-queen-20734

    02/01/2017, 9:18 PM
    an ADT would let the compiler do that
  • w

    witty-crayon-22786

    02/01/2017, 9:18 PM
    er, field-by-field
  • w

    witty-crayon-22786

    02/01/2017, 9:20 PM
    @fancy-queen-20734 : ok, commented
  • f

    fancy-queen-20734

    02/01/2017, 9:20 PM
    thanks
  • w

    witty-crayon-22786

    02/01/2017, 9:21 PM
  • w

    witty-crayon-22786

    02/01/2017, 9:22 PM
    but yea: what you said about holding them in typed collections would definitely affect the decision to declare an explicit struct type for an enum variant.
  • w

    witty-crayon-22786

    02/01/2017, 9:22 PM
    if you need a collection of 
    Inners
    , then rather than:
  • w

    witty-crayon-22786

    02/01/2017, 9:22 PM
    Copy code
    enum Entry {
  Root {
    subject_type: TypeId,
    selector: TypeConstraint,
  },
  Inner {
     subject_type: TypeId,
     rule: Task,
  }
  ...
}
  • w

    witty-crayon-22786

    02/01/2017, 9:22 PM
    you might do
  • w

    witty-crayon-22786

    02/01/2017, 9:22 PM
    Copy code
    struct Inner {..}

enum Entry {
  Root {
    subject_type: TypeId,
    selector: TypeConstraint,
  },
  Inner(Inner)
  ...
}
  • w

    witty-crayon-22786

    02/01/2017, 9:23 PM
    but in can be on a field-by-field basis, so
  • f

    fancy-queen-20734

    02/01/2017, 9:23 PM
    yeah. I’d tried the first thing, but it got a little confusing, then tried using boxed traits before going with the ugly but boring solution I posted
  • f

    fancy-queen-20734

    02/01/2017, 9:23 PM
    the enum with nested struct is much cleaner
  • w

    witty-crayon-22786

    02/01/2017, 9:23 PM
    eh, i don't find it boring... i find the panics terribly exciting 😉
1...219220221...906Latest