[MERGE] Nested trees: CompositeTree

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
>>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:
> 
>     aaron> Vincent Ladeuil wrote:
>     >> It isn't a *requirement*... 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'

Okay, so new mandatory parameters lead to errors, rather than silent
failures.

This can also be accomplished by doing

   def func(p1, p2, opt=None, p3=None):
      if p3 is None:
          raise ValueError('p3 is now required.')

I think that this approach is more backwards-compatible.  And typically,
we go through a period of warning that p3 is should now be supplied,
rather than immediately breaking.

> or
> 
>    def func(p1, p2, more_important_opt=None, opt=None):
>        pass
> 
> 1 is right while 2 became silently wrong again

So this is your response to "If we always specified the names for
optional parameters, changing their position would never be an advantage."?

I don't think that's enough reason to change the order of parameters.

>     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 :)

You might not be, but I am making the case that the rule will not always
be followed.  This is an example of breaking it in retrospect.

>     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 :)

No, there's sharp distinction between "none" and "few".  If there are
no places where we haven't followed this rule, we don't need to update
the callsites.  If there are only a few places where we haven't followed
this rule, we still need to examine all the callsites when changing the
ordering, and once we're looking at all the callsites, the additional
effort of fixing callsites is pretty small.

> <snip/>
> 
>     >> With that rule only the *required* parameters order remains
>     >> important.
> 
>     aaron> As long as you *can* specify them by 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 :)

No, a good reason to not try to respect a rule is that the rule's
benefits are less than its costs.  I believe YAGNI applies to this rule.
 For every case where it might help, there will be a hundred where it
doesn't.  And even when it helps, it won't help enough.

>     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

I don't think of them that way.  I think of them as parameters with
defaults and parameters with no defaults.

>     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.

So this means that your p3 example doesn't justify this rule?  We have
only the case where "def func(p1, p2, opt=None)" becomes "def func(p1,
p2, more_important_opt=None, opt=None)"?

That really seems like a lot of effort for very little gain.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknnSkgACgkQ0F+nu1YWqI3BTACfcZiKOoDXd8N5KtgmfCGF7d7W
mvkAn3Hh85cuDG+Ja2uvLBU3MXNZKHFk
=yshC
-----END PGP SIGNATURE-----