[MERGE] Nested trees: CompositeTree

[Aaron Bentley]

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

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.

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

The only thing I can see is that perhaps you want to change their
position anyway.  But over time, mandatory parameters can become
optional, and we don't change the calling code when that happens.  There
may also be plugins that don't adhere to this rule.

I don't think it's ever safe to assume that this rule has been followed
everywhere.  And if we can't, then I don't think there's an advantage to
following it anywhere.

> It isn't perfect either (ever heard about 'ignore_fallbacks'
> backtraces :), yet it helps.
> 
>     aaron> Is it not an API break to change the position of any
>     aaron> parameter?
> 
> In the general case yes. That's exactly the reason John (and I
> strongly agree and try to do the same) proposed to always specify
> names for *optional* parameters.
> 
> With that rule only the *required* parameters order remains
> important.

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

>     aaron> If not, then shouldn't we specify the names of all
>     aaron> parameters, not just optional ones?
> 
> Specifying names is harder to type and to read

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

> I think the
> policy is a trade-off trying to increase overall comfort, a bit
> more effort now, for hopefully less effort later.

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

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

iEYEARECAAYFAknnItUACgkQ0F+nu1YWqI1x2ACcDDBH58am/d/d9cjOOmwCOOsY
I5MAnR1y6COhX+2abKpAhMZpO/KYR8KT
=CC6C
-----END PGP SIGNATURE-----