mutable default parameter problem [Prothon]

[Mark Hahn]

Dave Brueck wrote:

> You cut out my example that elaborated on the questions I was asking:

Sorry.

> 1) It's just part of the name. So from the language's perspective,
> whether you call it appendINPLACE or append! makes no difference?

It makes no difference to the interpreter, but to the other Prothon
programmers it makes a difference because it's a convention.  Also append!()
is a standard library function so you don't get to change it :-)

> 2) (continuing on #1) that being the case, it's really just a naming
> convention, correct? (because the language itself doesn't do anything
> with that information - additional checking to enforce that
> convention, different functionality, etc)
>
>> From what I gather that's a "yes" to both questions.

Yes, Yes.

>>> Seems like a waste to reserve a
>>> symbol for something so rarely needed.
>>
>> I disagree.  In-place modification is significant and happens often.
>> Ignoring this is dangerous.
>
> Well, now we're down to disagreeing how often it occurs. I just
> haven't seen very many cases in practice where (1) I want to both do
> something to an object AND have it return itself in a single step and
> (2) doing so can be done in a clear way, and (3) I want to do it for
> a good reason rather than just wanting to save a line of code. In the
> few cases I've seen so far, the rationale has apparently been to make
> the code shorter, not necessarily better.

There are many clean readable programming conventions that rely on return
values.  This is certainly an acceptable construct, right?

    while len(list.append!(x)) < 10:
            blah blah blah

Compare that to the less readable and less maintainable Python version:

    list.append(x)
    while len(list) < 10:
            blah blah
            list.append(x)   # duplicate code

I can come up with many more.  I think when you have been without a language
feature for a while you tend to block it out of your mind.

>> How can you argue that the exclamation mark indicating
>> in-place-modification does not make it more readable?
>
> (1) Because in practice I haven't seen the need for it much,

You don't look for it because in the back of your mind you know you can't
use it.

> it encourages
> cramming more onto a line just because you can.

You are being pretty negative here.  Not everyone is out to cram more into a
line.  Give people a little more credit.

> The "print list.append!(5)" is a fine example of this IMO - you've
> combined two *completely unrelated* operations for no good reason.
> Yes, it's just an example, I know, but it's probably an example of
> how it'll be commonly (mis)used. For every one "good" use of the !
> form you'll probably have a thousand uses where the only benefit was
> that it saved a line of code. <0.5 wink>

I don't think I commited any big sin.  It seemed plenty readable to me.
Combining operations on one line is done all the time.  I suppose you would
code this:

    x = a + b
    x = x * c
    print x

instead of this:

    print (a+b) * c

> (2) It's just a naming convention, so you can't rely on it's presence
> or absence as being accurate (probably not a big deal in practice, but
> still...)

All programming involves trust.  Any programmer can obfuscate his code a
million ways.

> (3) Cases like w = x.y.z!() would confuse me, as would
>
> ref! = obj.method!

You are confused pretty easily.  Maybe because you aren't used to them.
They read easily to me.

> x = ref!(5, 6, 7) # what the heck, x == obj?!

ref! is invalid by convention and obj?! would throw a syntax exception.