From kry|ov@r00t @end|ng |rom gm@||@com  Fri Sep  1 16:24:43 2023
From: kry|ov@r00t @end|ng |rom gm@||@com (Ivan Krylov)
Date: Fri, 1 Sep 2023 17:24:43 +0300
Subject: [Rd] Updated `dendrapply`
In-Reply-To: <BL0PR04MB470648B7E324632897EF4EEDD9E5A@BL0PR04MB4706.namprd04.prod.outlook.com>
References: <BL0PR04MB470648B7E324632897EF4EEDD9E5A@BL0PR04MB4706.namprd04.prod.outlook.com>
Message-ID: <20230901172443.20f904a2@arachnoid>

? Fri, 1 Sep 2023 09:17:57 +0000
"Lakshman, Aidan H" <AHL27 at pitt.edu> ?????:

> - Ivan previously mentioned issues with user specific `[[.dendrogram`
> implementations, and it doesn't seem that you've fixed that.

> This is correct. I discovered during the R project sprint that
> `stats::dendrapply` does not respect user-specific implementations of
> `[[.dendrogram`. stats::`[[.dendrogram` has its own issues; if the
> user defines multiple classes for a dendrogram object, double bracket
> subsetting will remove the class (a bug report will be filed for this
> shortly).

True, my warning about not handing potential subclasses of dendrogram
was purely theoretical.

(A hypothetical subclass of dendrogram could work with the current
[[.dendrogram if it ensured that its own class name always precedes
'dendrogram' in the class vector, thus never being downstream from
stats:::`[[.dendrogram` in a chain of NextMethod() calls. But that's
still hypothetical.)

I see that your current implementation very nicely bounds the PROTECT()
stack usage and avoids the need to deallocate arbitrary SEXPs, which is
awkward to do with R's garbage collector API. Congratulations!

-- 
Best regards,
Ivan



[Rd] Updated `dendrapply`
Ivan Krylov