Message-ID: <CAM2gKPb9LzkXXDP1iBxek_jQLv1Sk_E7T9cOgU5WMrxB6KMy1w@mail.gmail.com>
Date: 2023-08-28T10:11:14Z
From: Konrad Rudolph
Subject: [External] Re: Calling a replacement function in a custom environment
In-Reply-To: <1997ca6e-d8e9-e473-5b0a-b16a75307958@uiowa.edu>
>
> I do not think it is a reasonable suggestion. The reasons a::b and
> a:::b were made to work is that many users read these as a single
> symbol, not a call to a binary operator. So supporting this helped to
> reduce confusion.
>
Conceptually, the same is true for `a$b` when `a` is used as an
environment. In fact, for environments `$` logically acts as a scope
resolution operator in much the same way `::` does. This usage exists
notably for ?R6? classes and ?box? modules, and the fact that replacement
functions cannot be called in such scenarios is a confusing limitation for
users of these packages.
In fact, if the aim of allowing replacement function calls for `a::b` is to
reduce confusion, the same argument applies to `a$b` (and users don?t
understand why the former works but the latter does not ? I?d even argue
that the current inconsistency *increases* rather than reduces confusion).
> In any case, complicating the complex assignment code, which is
> already barely maintainable, would be a very bad idea.
I generally agree with this, but the current behaviour is inconsistent,
confusing, and breaks seemingly-straightforward and actively useful code.
Cheers,
Konrad
--
Konrad Rudolph // @klmr
[[alternative HTML version deleted]]