Do you know why std.array.Appender defines a "put" method instead of overloading the "~=" operator?

Bye and thank you,
bearophile

On Wednesday, February 29, 2012 20:25:35 bearophile wrote:
> Do you know why std.array.Appender defines a "put" method instead of overloading the "~=" operator?

put is a function on output ranges, and Appender is an output range.

- Jonathan M Davis

Luckily you can always use alias this and overload opCatAssign. 'alias this' is a great tool for customizing APIs. :)

On Wednesday, February 29, 2012 20:53:04 Jonathan M Davis wrote:
> On Wednesday, February 29, 2012 20:25:35 bearophile wrote:
> > Do you know why std.array.Appender defines a "put" method instead of overloading the "~=" operator?
> 
> put is a function on output ranges, and Appender is an output range.

Also, given that it doesn't define ~ (and it wouldn't really make sense for it to), it would be very weird IMHO to define ~=.

- Jonathan M Davis

Jonathan M Davis:

> > put is a function on output ranges, and Appender is an output range.
> 
> Also, given that it doesn't define ~ (and it wouldn't really make sense for it to), it would be very weird IMHO to define ~=.

I don't understand why that's weird.
In Java you can't overload an append operator, so using a method is right. But for me it's weird that Appender doesn't use the D operator to _append_. I sometimes use "add" instead of "put" by mistake, forgetting the right method name, because I find it quite unnatural. If Appender needs a put, then I suggest to give it both "put" method and "~=" operator.

Bye,
bearophile

On Thursday, 1 March 2012 at 02:23:55 UTC, bearophile wrote:
> But for me it's weird that Appender doesn't use the D operator to _append_.  [...] I suggest to give it both "put" method and "~=" operator.

I agree entirely.


Another annoyance is if you have a function that works on
regular arrays, you probably used ~=.

But you decide to switch to Appender to try for a speed boost.

Now you have to change all the usage too, since the interfaces
are incompatible!

On Wednesday, February 29, 2012 21:23:54 bearophile wrote:
> Jonathan M Davis:
> > > put is a function on output ranges, and Appender is an output range.
> > 
> > Also, given that it doesn't define ~ (and it wouldn't really make sense for it to), it would be very weird IMHO to define ~=.
> 
> I don't understand why that's weird.
> In Java you can't overload an append operator, so using a method is right.
> But for me it's weird that Appender doesn't use the D operator to _append_.
> I sometimes use "add" instead of "put" by mistake, forgetting the right
> method name, because I find it quite unnatural. If Appender needs a put,
> then I suggest to give it both "put" method and "~=" operator.

Would you define += without defining +? Or *= without defining *? It strikes me as a misuse of operator overloading if you have an opOpAssign without its corresponding opBinary.

- Jonathan M Davis

On Thursday, March 01, 2012 03:29:06 Adam D. Ruppe wrote:
> On Thursday, 1 March 2012 at 02:23:55 UTC, bearophile wrote:
> > But for me it's weird that Appender doesn't use the D operator to _append_.  [...] I suggest to give it both "put" method and "~=" operator.
> 
> I agree entirely.
> 
> 
> Another annoyance is if you have a function that works on regular arrays, you probably used ~=.
> 
> But you decide to switch to Appender to try for a speed boost.
> 
> Now you have to change all the usage too, since the interfaces are incompatible!

True, but it can't do all of the other operations that array can do either. It's an output range, not an array. And odds are that it's going to be refactored such that it doesn't even contain an array internally anymore, beacause that's an inefficient way to implement appending. Someone (Robert Jacques IIRC, but I'd have to check) has already created such an implementation, and there's a decent chance that it's going to make it into Phobos.

So, I'm not sure that treating Appender as an array is really a good idea in the first place. If you want the truly generic approach, then treat is an output range.

- Jonathan M Davis

On Thursday, 1 March 2012 at 02:44:35 UTC, Jonathan M Davis wrote:
> True, but it can't do all of the other operations that array can do either.

Yeah, but the one operation it replaces, ~=, can be done
on an array.

If you're trying to convert array code to Appender for
speed, most likely you're going to be replacing a
bunch of ~= calls.

It's ok if the other op don't compile, but this one
really should. Appender, regardless of the internal
representation vs array is a speed optimization;
an implementation detail.

> It's an output range, not an array.

It's also an Appender, though. I think it is a little
silly to have an Appender to which you can't /append/.

(put is great too, don't get me wrong, but so is ~=).

On 1 March 2012 15:49, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Thursday, 1 March 2012 at 02:44:35 UTC, Jonathan M Davis wrote:
>>
>> True, but it can't do all of the other operations that array can do either.
>
>
> Yeah, but the one operation it replaces, ~=, can be done
> on an array.
>
> If you're trying to convert array code to Appender for
> speed, most likely you're going to be replacing a
> bunch of ~= calls.
>
> It's ok if the other op don't compile, but this one
> really should. Appender, regardless of the internal
> representation vs array is a speed optimization;
> an implementation detail.
>
>
>> It's an output range, not an array.
>
>
> It's also an Appender, though. I think it is a little
> silly to have an Appender to which you can't /append/.
>
> (put is great too, don't get me wrong, but so is ~=).

I can see both sides, but I'm on Adam's side here. While all the other opOpAssign functions are defined in terms of their opBinary equivalent (e.g, += is 'add and assign'), ~= is essentially an operator in its own right, specifically an append (as opposed to '~' which is concatenate). Having both ~= and .put() would be fine, and would make switching from arrays to Appenders much easier.

I understand that Appenders aren't arrays, and should not be used as such, but you /can/ use an array as an Appender. At some point, you have to concede design purity to convenience, otherwise you have a language that is actively hostile to changing designs. *In best "nagging wife" voice* "You should have used an Appender from the start. Now you have to go change all that code. Its your own fault really."...

--
James Miller