Date: Thu, 17 Mar 2022 00:42:37 +0200
On Thu, 17 Mar 2022 at 00:15, Tony V E <tvaneerd_at_[hidden]> wrote:
>> I fail to see why you and Nevin think hive should have an equality.
>
>
> Because conceptually, practically, and uh "patterningly" (ie pattern of other containers) it makes sense.
That explanation makes no sense to me. hive is substantially different
from other containers that I don't
know what concept you're talking about. Same goes for "patterningly"
and "practically".
> But by "practically" I mean, it is a normal thing to do with a container, and it can be useful.
I don't think it's in any way a normal thing to do with a hive.
>> None of that suggests to me that
>> we should perform hitherto untested heroics to get the equality,
> Well, it isn't really heroics, and wouldn't be untested.
Do we have a hive implementation that has field experience with an operator==?
>> especially when there's barely any use cases for it.
> I mostly agree. But if you never call it, then it is no big deal! :-)
Ah, like std::sort doesn't need to require a randomaccessrange, just
don't ever call it on a std::list? :)
>> The lack of
>> such an equality is just the nature of the beast of how hive works, if
>> you ask me.
> I don't think it is the nature of the concept of the container, but it is an outcome of how it would need to be implemented.
I fail to see the difference. hive makes particular trade-offs to
achieve its semantics and its performance guarantees,
and this is one of them. It arises out of the concept of the
container, and is therefore not just an implementation detail.
>> I fail to see why you and Nevin think hive should have an equality.
>
>
> Because conceptually, practically, and uh "patterningly" (ie pattern of other containers) it makes sense.
That explanation makes no sense to me. hive is substantially different
from other containers that I don't
know what concept you're talking about. Same goes for "patterningly"
and "practically".
> But by "practically" I mean, it is a normal thing to do with a container, and it can be useful.
I don't think it's in any way a normal thing to do with a hive.
>> None of that suggests to me that
>> we should perform hitherto untested heroics to get the equality,
> Well, it isn't really heroics, and wouldn't be untested.
Do we have a hive implementation that has field experience with an operator==?
>> especially when there's barely any use cases for it.
> I mostly agree. But if you never call it, then it is no big deal! :-)
Ah, like std::sort doesn't need to require a randomaccessrange, just
don't ever call it on a std::list? :)
>> The lack of
>> such an equality is just the nature of the beast of how hive works, if
>> you ask me.
> I don't think it is the nature of the concept of the container, but it is an outcome of how it would need to be implemented.
I fail to see the difference. hive makes particular trade-offs to
achieve its semantics and its performance guarantees,
and this is one of them. It arises out of the concept of the
container, and is therefore not just an implementation detail.
Received on 2022-03-16 22:42:49