New function: tq_index(); potentially change "get" arg to "type"; allow the "get" arg to take a vector

[DavisVaughan]

Abstractly, the types of data that tq_get() retrieves are all about a specific asset (the price of the asset, the financials of the asset, the dividends, etc) EXCEPT for "stock.index". This is not information about a specific asset, but a list of the assets themselves.

With that in mind, maybe it would make sense to separate tq_index() as it's own function, taking exchange = as an argument or something similar.

Then, it would make sense to allow tq_get() to take in a vector in the get/type argument.

If, for example, you did the following:

tq_index("SP500") %>% tq_get(type = c("stock.prices", "financials"))

wouldn't it be cool if that returned a nested tibble of 500 rows, with columns of symbol, stock_price, and financials, where stock_price and financials are list-columns for that row?

#symbol  stock_price   financials
#AAPL    [tibble RxC]  [tibble RxC]

[mdancho84]

@DavisVaughan:
I forgot to mention this during our discussion with @hadleywickham, but the type argument is more likely to be used in underlying quantmod functions, which is why I chose get in the first place. I did originally have it as type but was concerned about quantmod. Plus this will minimize the amount of changes for users that are just getting to know it. If it's all the same, I'd prefer to leave the get argument as "get" rather than change to "type".

I will still do the splitting out of the "stock.index" option, to tq_index() and add the functionality for compound getters (e.g. c("stock.prices", "financials"). These are excellent ideas.

[DavisVaughan]

@mdancho84 the only other synonym for this that I can think of would be info. My main rationale for info or type over get is a grammatical one. The function name tq_get() is sensibly a verb saying what you want to do, and I think it makes sense to then have the arguments as nouns of what you want the function to compute on. In the end, it doesn't matter much, and to me it is just as easy to keep it as get, but I figured I would explain my reasoning.

In terms of keeping users from being confused, deprecation is an option. I wouldn't be surprised if you already knew about this, just sharing.

Sounds great about tq_index() and the compound getters! Keep up the great work.

[mdancho84]

I agree that it should be a noun. Just thinking that type was already used. Let me think it over and try a few things.

[mdancho84]

@DavisVaughan I believe all of the functionality is incorporated correctly. When you get a FREE moment, please let me know if it works as you expect. A few notes:

• I added tq_index() and deprecated tq_get(get = "stock.index"). tq_index_options() provides the list of options and deprecates tq_get_stock_index_options(). I think everyone will appreciate this!
• I included functionality for compound getters within tq_get(). Now the user can get a lot of information in one data frame, such as:

c("AAPL", "GOOG") %>%
    tq_get(get = c("stock.prices", "financials"))

• I added an argument, complete_cases that defaults to TRUE. Complete cases removes any symbols with errors during the "get" process, which is 99.9% of the time what the user should want. If the user sets complete_cases = FALSE, the user get a "nested" data frame if an error is detected. Both situations will result in (1) the operation will not fail and (2) the user gets warnings on what symbols have errors. This is good for scaling. See examples below:

# Removes rows with NA's returned in the getting process
c("AAPL", "GOOG", "BAD_APPLE") %>%
    tq_get(get = "stock.prices", complete_cases = TRUE)

# Keeps rows with NA's returned in the getting process
c("AAPL", "GOOG", "BAD_APPLE") %>%
    tq_get(get = "stock.prices", complete_cases = FALSE)

Let me know your thoughts and if we can close out.

Thanks, Matt