Object `+= lfuns are not called when they should have been.
It appears that we don't call += lfuns directly, instead we
expand a += b+c into a = a+b+c.
Well, that is all fine and dandy, but, the f_add function then
tries to fold this back into a += by checking if the number of refs
on the object
a += b is a shorthand for a = a + b, so the refs==1 check is the only
correct condition for when to use the `+= lfun. The `+= lfun therefore
is _not_ operator overloading for +=, but rather an optimization for
when a has only one reference. This is compatible with how += works
on other types,
Arne Goedeke wrote:
a += b is a shorthand for a = a + b, so the refs==1 check is the only
correct condition for when to use the `+= lfun. The `+= lfun therefore
is _not_ operator overloading for +=, but rather an optimization for
when a has only one reference.
Yes, that seems to describe what
On Mon, Sep 8, 2014 at 2:21 PM, Stephen R. van den Berg s...@cuci.nl wrote:
Arne Goedeke wrote:
a += b is a shorthand for a = a + b, so the refs==1 check is the only
correct condition for when to use the `+= lfun. The `+= lfun therefore
is _not_ operator overloading for +=, but rather an
On Mon, Sep 8, 2014 at 10:21 PM, Stephen R. van den Berg s...@cuci.nl wrote:
The question now remains:
- Do we agree this is a bug?
- Or do we document that this is a feature?
- Or maybe we already documented it as a feature and I just didn't see it.
It's documented here:
Tobias S. Josefowitz wrote:
Then they should have read the docs:
http://pike.lysator.liu.se/generated/manual/modref/ex/lfun_3A_3A/_backtick_add_eq.html
Ok, it was option three then, I guess. I apologise for the noise.
Let the record show though that I consider it to be a rather messy way
to
Chris Angelico wrote:
On Mon, Sep 8, 2014 at 10:21 PM, Stephen R. van den Berg s...@cuci.nl wrote:
- Or maybe we already documented it as a feature and I just didn't see it.
But it's a distinct difference from, say, the Python equivalent, so
it's worth making sure it's properly visible. Where
On Mon, Sep 8, 2014 at 10:30 PM, Stephen R. van den Berg s...@cuci.nl wrote:
Let the record show though that I consider it to be a rather messy way
to handle this :-).
I've worked with Python's way of doing things, and it has its own
issues. This kind of thing comes up periodically on
Ah. So that is why nobody is replying to the mails I send.
It would appear that the KOM-email bridge is not working correctly,
so the last few replies I have written have not, actually, been sent.
First, on this topic:
Object `+= lfuns are not called when they should have been.
Well. That
On Mon, Sep 8, 2014 at 10:38 PM, Stephen R. van den Berg s...@cuci.nl wrote:
Well, for one, someone browsing the docs needs to be explained the difference
between
http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/_backtick_add.html
and
Per Hedbor wrote:
Sorry about the timing, I have had IOBuffer on the way for some time
(I am still wondering where to put it, however, that has, believe it
or not, been a blocker for me. Perhaps Stdio.Buffer? I will create a
buffered stream that reads to and writes from said object, without
Generally speaking, buffers help enormously when reading and
parsing from bytestreams into pike, but they do not help all that
much when writing to bytestreams. The writev() system call handles
the fragmented writes quite nicely (see the pgsql driver) and more efficient
than an IOBuffer
Per Hedbor wrote:
Generally speaking, buffers help enormously when reading and
parsing from bytestreams into pike, but they do not help all that
much when writing to bytestreams. The writev() system call handles
the fragmented writes quite nicely (see the pgsql driver) and more efficient
13 matches
Mail list logo
