Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      lots of duplication, use a vector of events or something

        Issue Links

          Activity

          Hide
          Gustavo Salazar Torres added a comment -

          Hmm, a state machine would be cleaner (nice project Ragel, didn't hear about it). I will work on something simpler like you suggested and leave performance for another JIRA.

          Show
          Gustavo Salazar Torres added a comment - Hmm, a state machine would be cleaner (nice project Ragel, didn't hear about it). I will work on something simpler like you suggested and leave performance for another JIRA.
          Hide
          Nitay Joffe added a comment -

          That sounds great yeah. You can probably just implement the trigger() method inside PredicateLock itself. I'll let you play with it and figure out cleanest solution.

          I think in terms of performance we can do a bit better. The nature of the if/else-if/else-if... is that only one can ever run right. In that case it seems like we should be able to a simple map lookup type thing. It may be tricky because although the type checks are always just == the path checks equals(), contains() others, and endsWith()... Looking at the code I think the endsWith() is equivalent to using equals() on the last entry in the path (`basename`).
          Really at a high level each signal trigger is a Pair<EventType,path-regex> and this is a list of matchers. We could get fun with this and just write a state machine with something like Ragel (google it) and use that to spit out some simple Enum value of which trigger matched the path. This is probably all overkill though, but I like languages .
          Anyways for now I think your solution is good let's do that, and if you're interested in further exploring performance improvements we can do it in another JIRA.

          Show
          Nitay Joffe added a comment - That sounds great yeah. You can probably just implement the trigger() method inside PredicateLock itself. I'll let you play with it and figure out cleanest solution. I think in terms of performance we can do a bit better. The nature of the if/else-if/else-if... is that only one can ever run right. In that case it seems like we should be able to a simple map lookup type thing. It may be tricky because although the type checks are always just == the path checks equals(), contains() others, and endsWith()... Looking at the code I think the endsWith() is equivalent to using equals() on the last entry in the path (`basename`). Really at a high level each signal trigger is a Pair<EventType,path-regex> and this is a list of matchers. We could get fun with this and just write a state machine with something like Ragel (google it) and use that to spit out some simple Enum value of which trigger matched the path. This is probably all overkill though, but I like languages . Anyways for now I think your solution is good let's do that, and if you're interested in further exploring performance improvements we can do it in another JIRA.
          Hide
          Gustavo Salazar Torres added a comment -

          I see there are many if...else's checking for conditions before signaling BspEvent's signal method. I was thinking to create a BspEventTrigger interface with an evaluate method. EventTrigger classes would hold a BspEvent instance and "evaluate" method would decide whether to call or not BspEvent's signal method.
          BspService would hold an array of BspEventTrigger instances like you suggested but if some trigger returns "true" on "evaluate" method then it will stop calling any other.
          What do you think?

          Show
          Gustavo Salazar Torres added a comment - I see there are many if...else's checking for conditions before signaling BspEvent's signal method. I was thinking to create a BspEventTrigger interface with an evaluate method. EventTrigger classes would hold a BspEvent instance and "evaluate" method would decide whether to call or not BspEvent's signal method. BspService would hold an array of BspEventTrigger instances like you suggested but if some trigger returns "true" on "evaluate" method then it will stop calling any other. What do you think?

            People

            • Assignee:
              Unassigned
              Reporter:
              Nitay Joffe
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development