[MERGE] Nested trees: CompositeTree

[Vincent Ladeuil]

>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:

    aaron> Vincent Ladeuil wrote:
    >>>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:
    >> 
    >> <snip/>
    >> 
    >> >> John has been promoting a policy of explicitly naming
    >> >> optional parameters rather than relying on their position
    >> >> being unchanged.
    >> 
    aaron> I don't think I've ever heard that suggested before.
    >> 
    >> It has been discussed at several occasions, from memory I'd say
    >> during reviews, so that may explain you didn't notice.
    >> 
    >> It isn't a *requirement*, we have no way to really enforce it,
    >> it's just that it provides some room regarding backward
    >> compatibility.

    aaron> What kind of room?  If we always specified the names
    aaron> for optional parameters, changing their position would
    aaron> never be an advantage.

Compare:

   def func(p1, p2)
       pass
   
   func('a', 'b')

then

   def func(p1, p2, opt=None):
       pass

(1)   func('a', 'b', opt='c')
(2)   func('a', 'b', 'c')

then

   def func(p1, p2, p3, opt=None):
      pass

1 is wrong but 2 became silently wrong


or

   def func(p1, p2, more_important_opt=None, opt=None):
       pass

1 is right while 2 became silently wrong again


    aaron> The only thing I can see is that perhaps you want to
    aaron> change their position anyway.  But over time,
    aaron> mandatory parameters can become optional, and we don't
    aaron> change the calling code when that happens.

Right, we're not talking about that case :)

    aaron> There may also be plugins that don't adhere to this
    aaron> rule.

I know, that's why I say we can't enforce it (but it can be
applied to private functions/methods too, so plugins aren't
always concerned anyway), but the more we respect it the less
maintenance for us.

    aaron> I don't think it's ever safe to assume that this rule
    aaron> has been followed everywhere.

Of course !

    aaron> And if we can't, then I don't think there's an
    aaron> advantage to following it anywhere.

As you say later, it's not black-and-white :)

<snip/>

    >> With that rule only the *required* parameters order remains
    >> important.

    aaron> I don't agree.  I think you need a new programming
    aaron> language to make the order of optional parameters
    aaron> unimportant.  As long as you *can* specify them by
    aaron> position, there will be cases of it.

That's exactly why we would prefer to *avoid* them. We all agree
that there will be violations, but is that a good reason to not
try to respect a rule :)

<snip/>

    aaron> I don't think it's black-and-white.  Specifying the
    aaron> name of a boolean value generally enhances readability
    aaron> for me.  Generally, if the value doesn't express its
    aaron> meaning, then specifying the name improves
    aaron> readability.

I think another reason here to name optional parameters (at least
for me) is that if they are optional:

1 - I don't have to specify them most of the time
2- using their name reminds me that I'm activating an option

<snip/>

    aaron> I still don't understand what later effort we're
    aaron> trying to avoid.

Updating all call sites without a true need. We should do that
only when adding mandatory parameters.

     Vincent