Alternative implementation: lookahead/lookbehind about stringr.plus HOT 2 CLOSED

Oooo! This is fun. Thanks! I really appreciate you taking the time to read the code!

I have heard of and maybe used lookaheads and lookbefores a couple of times. I knew they were an option, but just went with what I had more experience using.

Couple questions for you, since you know more about package maintenance than I do. Can you explain a bit about how it might be more maintainable? Is this in case stringr::str_locate() changes down the road?

I'm thinking if I paired your solution there with grep instead of str_extract and paste0 rather than glue, there would be no non-base dependencies, right?

from stringr.plus.

You could certainly do that...

str_before <- function(string, pattern, n = NULL) {
  n_str <- ifelse(is.null(n), "(^.*?", paste0("^.*?(.{", n, "}"))
  new_pattern <- paste0(n_str, ")(?=", pattern, ").*$")
  sub(new_pattern, "\\1", string, perl = TRUE)
}
url <- "www.carfax.com/vehicle/3GCPKTE77DG348900"
str_before(url, "/")
#> [1] "www.carfax.com"
str_before(url, ".com")
#> [1] "www.carfax"
str_before(url, ".com", 6)
#> [1] "carfax"

str_after <- function(string, pattern, n = NULL) {
  n_str <- ifelse(is.null(n), "(.*$)", paste0("(.{", n, "}).*?$"))
  new_pattern <- paste0("^.*?(?<=", pattern, ")", n_str)
  sub(new_pattern, "\\1", string, perl = TRUE)
}
url <- "www.carfax.com/vehicle/3GCPKTE77DG348900"
str_after(url, "/")
#> [1] "vehicle/3GCPKTE77DG348900"
str_after(url, "vehicle/")
#> [1] "3GCPKTE77DG348900"
str_after(url, "vehicle/", 6)
#> [1] "3GCPKT"

^{Created on 2020-08-16 by the reprex package (v0.3.0)}

By "easier to maintain" I mean the effort required to ensure that you don't introduce any new bugs. By using the {stringr} functions you rely on their testing - in my first example I'm introducing very little new code so few places it could go wrong that won't already go wrong in {stringr}. This version has more complexity, but fewer dependencies, so that's a tradeoff. The more expressions you add to a function, the more places for bugs to hide.

In this case you're not benefiting from the nice wrappers that {stringr} has, another tradeoff.

These are useful patterns, so ironing out the wrinkles and making them available is of great benefit.

from stringr.plus.