Winston Chang
Winston Chang
That does sound like it could be useful. I'd be happy to look at a PR.
This is a bug. I think that it makes sense to disallow overriding in either direction, from method->field or field->method, because then the subclass will behave differently from the superclass.
I was wondering about the use case you had in mind. We've been thinking about interfaces for R6, but haven't yet decided on a course of action (#163).
The problem is that the default is `TRUE`. In retrospect, the default should have been `FALSE`, but it's too late to make that change now.
For multiple inheritance, maybe it could take the AND of the parents' values for `cloneable` by default.
I like the idea of a `post_clone()` method. Another idea, as was suggested in #110, is to rename the current `clone` method to `.clone`, and then define `clone = function()...
Actually, now that I think if it, I think that it's a little confusing that both `lazyeval::ast_` and `lobstr::ast` do some sort of quosure unwrapping. The actual call has a...
I think it's not quite the same -- what I'm asking for here is for quosures to _not_ be specially printed (because currently, they're magically hidden), but #27 is asking...
Yes, it would be breaking, so it would be a good idea to do something like what you propose. Maybe start with messages and then in, say, a year, upgrade...
I just released v2.4.0, which allows private finalizers. The documentation now says that finalizers should be private, but they are allowed to be public or private. In the future --...