[prev in list] [next in list] [prev in thread] [next in thread] 

List:       r-devel
Subject:    Re: [Rd] [External] Re: Calling a replacement function in a custom environment
From:       Konrad Rudolph <konrad.rudolph () gmail ! com>
Date:       2023-08-28 10:11:14
Message-ID: CAM2gKPb9LzkXXDP1iBxek_jQLv1Sk_E7T9cOgU5WMrxB6KMy1w () mail ! gmail ! com
[Download RAW message or body]

>
> 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]]

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[prev in list] [next in list] [prev in thread] [next in thread]