From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id D53C31F406; Sun, 31 Dec 2017 22:22:07 +0000 (UTC) Date: Sun, 31 Dec 2017 22:22:07 +0000 From: Eric Wong To: Dimid Duchovny Cc: msgthr-public@80x24.org Subject: Re: library usage Message-ID: <20171231222207.GA1541@80x24.org> References: <20171227180157.GA10868@starla> <20171228014329.GA15938@starla> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Dimid Duchovny wrote: > Thank you very much Eric! > As a matter of fact, I did find an issue, which I'm not sure is a bug; > consider this line from the `add` method: > cur = @id_table[mid] ||= Msgthr::Container.new(mid) > > If `mid` is the empty string or a string which only contains > whitespace, it's considered a valid key for `id_table`. > However, I'd expect an empty string and (arguably) whitespace-only > strings to be equivalent to nil. If msgthr were only for RFC822-like (email/news) messages, I'd be inclined to agree with you. However, msgthr could also be loading messages off something like an SQL DB, where "" and NULL are distinctly different (yet still likely a bug in the DB design/code). So in that case; I don't think we should be assuming anything about the users' data and potentially hiding bugs. > Happy new year! Same to you :) I'm looking forward to having more time to work on mail-related tools in 2018.