Remove "get_" prefixes from function names

[jgabry]

Suggestion from @bob-carpenter:

I'd recommend removing "get_" prefixes; "set_" is OK, but "get_" doesn't
really add any info, just four more characters.

I'm fine with deprecating the functions with get_ prefixes (get_sampler_params, get_inits, etc.). I don't think we would have any name conflicts with existing functions, so we should be able to just drop the get_ prefixes and keep the resulting function names. Eventually we can disallow the get_ versions entirely.

[bgoodri]

This is not unrelated to the question of whether to move to reference classes for RStan3.

[bob-carpenter]

Do they dicatate the names of getters/setters? If so,
I'd prefer to favor consistency over conciseness.

• Bob

On Mar 9, 2016, at 10:49 PM, bgoodri notifications@github.com wrote:

This is not unrelated to the question of whether to move to reference classes for RStan3.

—
Reply to this email directly or view it on GitHub.

[bgoodri]

By default, you can do $foo to get foo, but they also support $getfoo().

On Thu, Mar 10, 2016 at 2:57 PM, Bob Carpenter notifications@github.com
wrote:

Do they dicatate the names of getters/setters? If so,
I'd prefer to favor consistency over conciseness.

• Bob

On Mar 9, 2016, at 10:49 PM, bgoodri notifications@github.com wrote:

This is not unrelated to the question of whether to move to reference
classes for RStan3.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#276 (comment).

[sakrejda]

I've done a few packages using reference classes and I usually use the same
name for the getter/setter. If you keep a protected internal variable
(e.g.-foo$bar__, then the getter setter foo$bar(x=NULL) can return the
value foo$bar__ when x is NULL and set otherwise (the syntax foo$bar <- 3
calls foo$bar(x=3)). If it's a read-only variable you can just test 'x'
and throw an error if !is.null(x). There's probably a few other ways of
doing this but if you don't protect read-only variables it gets easy for
users to wreck the state of the object.

On Thu, Mar 10, 2016 at 3:08 PM, bgoodri notifications@github.com wrote:

By default, you can do $foo to get foo, but they also support $getfoo().

On Thu, Mar 10, 2016 at 2:57 PM, Bob Carpenter notifications@github.com
wrote:

Do they dicatate the names of getters/setters? If so,
I'd prefer to favor consistency over conciseness.

• Bob

On Mar 9, 2016, at 10:49 PM, bgoodri notifications@github.com wrote:

This is not unrelated to the question of whether to move to reference
classes for RStan3.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#276 (comment).

—
Reply to this email directly or view it on GitHub
#276 (comment).

[bob-carpenter]

On Mar 10, 2016, at 3:16 PM, Krzysztof Sakrejda notifications@github.com wrote:

I've done a few packages using reference classes and I usually use the same
name for the getter/setter. If you keep a protected internal variable
(e.g.-foo$bar__, then the getter setter foo$bar(x=NULL) can return the
value foo$bar__ when x is NULL and set otherwise (the syntax foo$bar <- 3
calls foo$bar(x=3)).

I take it then the use would be

get value of bar: foo$bar()
set bar to 3: foo$bar(3)

The full form foo$bar(x = 3) looks really confusing.

I find that pretty confusing, but I find the rest of R confusing,
too.

If it's a read-only variable you can just test 'x'
and throw an error if !is.null(x). There's probably a few other ways of
doing this but if you don't protect read-only variables it gets easy for
users to wreck the state of the object.

Absolutely. On construction, objects should be in a good
state and setters should maintain that good state. That's why
I don't like the lm() return in R --- it's easy to set it into
an inconsistent state.

• Bob

On Thu, Mar 10, 2016 at 3:08 PM, bgoodri notifications@github.com wrote:

By default, you can do $foo to get foo, but they also support $getfoo().

On Thu, Mar 10, 2016 at 2:57 PM, Bob Carpenter notifications@github.com
wrote:

Do they dicatate the names of getters/setters? If so,
I'd prefer to favor consistency over conciseness.

• Bob

On Mar 9, 2016, at 10:49 PM, bgoodri notifications@github.com wrote:

This is not unrelated to the question of whether to move to reference
classes for RStan3.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#276 (comment).

—
Reply to this email directly or view it on GitHub
#276 (comment).

—
Reply to this email directly or view it on GitHub.

[ariddell]

PyStan can mirror this change. It happens to be more in keeping with Python conventions.

[davharris]

Regarding reference semantics, I haven't felt much need for it in rstan. If rstan does go that route, it might be worth considering R6 classes (designed and maintained by the RStudio folks) over reference classes:

They’re similar to R’s built-in reference classes, but are simpler, smaller, and faster, and they allow inheritance across packages.

[bgoodri]

Yeah, R6 is on the table, although my sense is that John Chambers fixed
most of the limitations of reference classes that originally motivated the
RStudio people to create R6.

On Mon, Oct 10, 2016 at 12:53 PM, David J. Harris notifications@github.com
wrote:

Regarding reference semantics, I haven't felt much need for it in rstan.
If rstan does go that route, it might be worth considering R6 classes
https://cran.r-project.org/web/packages/R6/vignettes/Introduction.html
(designed and maintained by the RStudio folks) over reference classes:

They’re similar to R’s built-in reference classes, but are simpler,
smaller, and faster, and they allow inheritance across packages.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#276 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADOrqpOQdDWn6Jv1TZygG4qpjj7ofEp9ks5qym2fgaJpZM4HsL1j
.