On 25/02/16 23:50, Trevor Vaughan wrote:
I just want to make sure I'm reading this right.

For the first scenario, noop means don't order anything, just do things
in whatever order they happen.

And the second scenario is: don't fail B if A fails (don't create a
relationship), but do A before B

Is this correct?


I have problems understanding what you mean by noop and fail here.

The fundamental question is, does this expression define the order of A and B?

A -> [ ] -> B

You can view it either as it defines the order [A, B], or that it does not and their partial order is unaffected.

If you like the answer to be [A, B], does it bother you that the following is not the same thing:

A -> [ ]
[ ] -> B

As that would not order them - because [ ] here can be seen as either first/last or "in the partial order that is defined elsewhere".

Trying to make that define the order [A, B] is impossible since every resource starts out with the partial order [[], R, []] (nothing before R, nothing after R).

- henrik


If it is, I favor the second scenario as the default as it is more
intuitive to the 'ordered compile' of Puppet 3+.

Thanks,

Trevor

On Thu, Feb 25, 2016 at 5:31 PM, Henrik Lindberg
<henrik.lindb...@puppetlabs.com <mailto:henrik.lindb...@puppetlabs.com>>
wrote:

    On 25/02/16 22:08, John Bollinger wrote:



        On Thursday, February 25, 2016 at 8:55:01 AM UTC-6, Trevor
        Vaughan wrote:

             Hmm.....

             I think, as long as it is documented, then whatever behavior is
             deterministic is fine.
             '
             I think that there is value in the following resolutions:

             Notify['left'] -> [] -> Notify['right']
                * Noop since there is nothing in []

             Notify['left'] -> [] -> Notify['right']
             Notify['left'] -> Notify['right']
                * First == Noop
                * Second == Expected ordering



        I flip-flopped a bit on this.  I started from the position that
        it would
        be inappropriate for

        |
        Notify['left']->$stuff ->Notify['right']
        |

        or

        |
        Notify['left']->Stuff<||>->Notify['right']
        |

        ever to fail to cause Notify['left'] to be applied before
        Notify['right'], as indeed it now does fail to do in the event
        that the
        stuff in the middle represents zero resources.  My basis there
        was that
        it is counterintuitive for such expressions to not establish
        relative
        ordering of the two Notifys.

        Ultimately, however, that basis is completely subjective.
        Others might
        reasonably intuit that such an expression would have exactly the
        semantics it actually does have, which are roughly equivalent to
        those of

        |
        Notify['left']->$stuff
        $stuff ->Notify['right']
        |

        .  Upon reflection, this alternative is less magic.  It falls out
        naturally from understanding that chain operators associate from
        left to
        right, and that each binary chain expression /evaluates to/ the
        value of
        its right-hand operand.  That some people might find that behavior
        surprising is a consideration, but not a primary one for me.


    It depends on the operator if it is left or right associative and if
    it is cumulative. And also what the result of '(nothing) op
    (something)' results in.

    if
       (nothing) -> X
       X -> (nothing)

    both evaluate to X

    as in

       0 + 1
       1 + 0

    Then empty man in the middle would be a noop.

    If you consider the arrows to abstractly order a set of resources in
    an array which at the end of the chain defines the partial order of
    the resources it would be the same as doing array concatenation.

    i.e.
    [A] + [] + [B] = [A, B]

    So - it is all down to definition of the arrow operators; i.e.
    taste/most practical/least surprise.

    - henrik


    --

    Visit my Blog "Puppet on the Edge"
    http://puppet-on-the-edge.blogspot.se/

    --
    You received this message because you are subscribed to the Google
    Groups "Puppet Developers" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to puppet-dev+unsubscr...@googlegroups.com
    <mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
    To view this discussion on the web visit
    
https://groups.google.com/d/msgid/puppet-dev/56CF80DD.7010200%40puppetlabs.com.

    For more options, visit https://groups.google.com/d/optout.




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --

--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUmvhYvCOift0Hn8vAGPyO89TmnyLty2mcB4R47h1fB3g%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUmvhYvCOift0Hn8vAGPyO89TmnyLty2mcB4R47h1fB3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/56CF8A4D.3070004%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to