On Mon, 09 Jan 2012 13:35:26 -0500, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 1/9/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> BTW, dcollections' HashMap, HashSet, and HashMultiset do guarantee that
>> adding elements does not invalidated cursors (dcollections' safe version
>> of pointers) as long as you use the default Hash implementation.  However,
>> I just noticed this is not stated anywhere in the docs (will fix).
>
> Funny, I was looking at the docs a few days ago and it said "Adding an
> element can invalidate cursors depending on the implementation.", so I
> just assumed it did invalidate the cursors.

Yeah, I could have sworn I stated somewhere that the current implementation doesn't invalidate cursors, but apparently it's not stated.  I think the docs need a lot of TLC before the first release.  Some day when I have time...

To clarify what I plan to do, the add doc will say something like "adding an element can invalidate cursors depending on the implementation, however the default implementation guarantees not to invalidate them."  I don't want to specifically disallow implementations which do invalidate (dcollections' implementations are pluggable so anyone can replace the internals).

> I do think those are dcollections v1 docs though. Anyway glad to hear
> from you about this.

The D2 docs are somewhat leftover from D1 version.  However, I do remember when implementing the hash code that it purposely does not invalidate cursors on a rehash.  Ranges can be invalidated, however.  Given the implementation, it's actually faster *not* to invalidate them when rehashing because I just relink all the link-list nodes instead of reallocating them.

-Steve

Ok, allow me to temporarily hijack again and ask: Would you mind adding opIn_r (or rather the newer opBinaryRight with "in") that forwards to contains() for the HashSet and similar hash-based classes that define contains()? It would make porting code that uses builtin hashes to your own implementation easier.

On Mon, 09 Jan 2012 14:57:36 -0500, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Ok, allow me to temporarily hijack again and ask: Would you mind
> adding opIn_r (or rather the newer opBinaryRight with "in") that
> forwards to contains() for the HashSet and similar hash-based classes
> that define contains()? It would make porting code that uses builtin
> hashes to your own implementation easier.

Could this be you?

http://www.dsource.org/projects/dcollections/ticket/18

If so, this means you are OK with the last suggestion I made?

-Steve

On 1/9/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Could this be you?

Ah, yes. I didn't even notice you've replied to that, sorry. Yes, I'm ok with it.

dennis luehring wrote:
> why is there an exception/error neeeded if missing?

Exceptions or errors are not _needed_.

Their existence stems from the modell under which the user of the
operation _has_ to think about the operation, especially whether it
is
  a:only the outcome of the operation or
  b:the amount of work to get to this outcome
and maybe
  c:at runtime has to be known, whether the object exists.


Jesse Phillips wrote:
> I have a lot of if(exists) remove() in my code

As one can see, Jesse does not know, whether the object exists and has to ask, before he in fact removes the object, i.e. doubled access to the file, which may cause a slowdown.

As Jesse states the designer of the API has made up false assumptions about his knowledge, described in c:,  _and_ his interests, described in b:.

Jesse is interested only in the outcome of the operation, as described in a:,

Therefore the likely answer to your question stated at the beginning is: the designer of the API made a mistake.

-manfred

Am 09.01.2012 22:08, schrieb Manfred Nowak:
> dennis luehring wrote:
>>  why is there an exception/error neeeded if missing?
>
> Exceptions or errors are not _needed_.
>
> Their existence stems from the modell under which the user of the
> operation _has_ to think about the operation, especially whether it
> is
>    a:only the outcome of the operation or
>    b:the amount of work to get to this outcome
> and maybe
>    c:at runtime has to be known, whether the object exists.
>
>
> Jesse Phillips wrote:
>>  I have a lot of if(exists) remove() in my code
>
> As one can see, Jesse does not know, whether the object exists and
> has to ask, before he in fact removes the object, i.e. doubled access
> to the file, which may cause a slowdown.

so your FileDelete would not return an FileDoesNotExists-Error?

it isn't always clear what is "ok" to happen - there are million types of remove-like-semantic, an Jesse's scenario is one type of usage, which other type of remove allows silently non-remove-removes? STL? Python, etc. (how do others handle such cases)

would it not help to better understand big code if the remove would be renamed to remove_existing or to add something like this?

dennis luehring wrote:

> so your FileDelete would not return an FileDoesNotExists-Error?
Correct.

> would it not help to better understand big code if the remove would be renamed to remove_existing or to add something like this?
Maybe.

You possibly know about the `rm'-command of *nix-like systems and the
by typo inserted space, which makes
  `rm -r *.obj' to
  `rm -r * .obj'
This will certainly result in the nice error-message:
  "cannot remove `.obj': No such file or directory"

Therefore: trying to help a minority possibly routes the majority.

-manfred