Problem accumulating/appending values in an array using recursion with Go
up vote
-1
down vote
favorite
First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.
Code description:
I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.
This is what I did so far:
I have the these two functions:
func request(requestData *RequestData) *ProjectsResponse {
client := &http.Client{
Timeout: time.Second * 10,
}
projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)
return projects
}
func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {
if URL == "" {
return
}
req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))
res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)
if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)
if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}
projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}
Undesired behavior:
The values in the projects *ProjectsResponse
array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests
ends, in the project
variable inside the request
method I get nothing.
Hope somebody and spot my mistake.
Thanks in advance.
arrays go
add a comment |
up vote
-1
down vote
favorite
First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.
Code description:
I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.
This is what I did so far:
I have the these two functions:
func request(requestData *RequestData) *ProjectsResponse {
client := &http.Client{
Timeout: time.Second * 10,
}
projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)
return projects
}
func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {
if URL == "" {
return
}
req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))
res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)
if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)
if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}
projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}
Undesired behavior:
The values in the projects *ProjectsResponse
array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests
ends, in the project
variable inside the request
method I get nothing.
Hope somebody and spot my mistake.
Thanks in advance.
arrays go
1
Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.
– RayfenWindspear
Nov 19 at 22:27
Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)
– Marcote
Nov 19 at 22:34
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.
Code description:
I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.
This is what I did so far:
I have the these two functions:
func request(requestData *RequestData) *ProjectsResponse {
client := &http.Client{
Timeout: time.Second * 10,
}
projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)
return projects
}
func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {
if URL == "" {
return
}
req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))
res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)
if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)
if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}
projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}
Undesired behavior:
The values in the projects *ProjectsResponse
array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests
ends, in the project
variable inside the request
method I get nothing.
Hope somebody and spot my mistake.
Thanks in advance.
arrays go
First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.
Code description:
I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.
This is what I did so far:
I have the these two functions:
func request(requestData *RequestData) *ProjectsResponse {
client := &http.Client{
Timeout: time.Second * 10,
}
projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)
return projects
}
func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {
if URL == "" {
return
}
req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))
res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)
if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)
if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}
projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}
Undesired behavior:
The values in the projects *ProjectsResponse
array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests
ends, in the project
variable inside the request
method I get nothing.
Hope somebody and spot my mistake.
Thanks in advance.
arrays go
arrays go
edited Nov 19 at 22:28
asked Nov 19 at 22:10
Marcote
2,17411620
2,17411620
1
Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.
– RayfenWindspear
Nov 19 at 22:27
Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)
– Marcote
Nov 19 at 22:34
add a comment |
1
Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.
– RayfenWindspear
Nov 19 at 22:27
Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)
– Marcote
Nov 19 at 22:34
1
1
Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.
– RayfenWindspear
Nov 19 at 22:27
Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.
– RayfenWindspear
Nov 19 at 22:27
Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)
– Marcote
Nov 19 at 22:34
Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)
– Marcote
Nov 19 at 22:34
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...
func innerRequest(client *http.Client, URL string) *ProjectsResponse {
if URL == "" {
return nil
}
//More code...
pagingData := getPageInformation(res)
return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
}
add a comment |
up vote
1
down vote
The confusion lies in the way a slice
is handled in Go. Here is the in-depth explanation, but I will abbreviate.
The common misconception is that the slice
you pass around is a reference to the slice
, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct
with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.
Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)
Playground link: https://play.golang.org/p/v5XeYpH1VlF
// correct way to return from recursion
func addReturn(s int) int {
if finalCondition(s) {
return s
}
s = append(s, 1)
return addReturn(s)
}
// using a reference
func addReference(s *int) {
if finalCondition(*s) {
return
}
*s = append(*s, 1)
addReference(s)
}
// whatever terminates the recursion
func finalCondition(s int) bool {
if len(s) >= 10 {
return true
}
return false
}
1
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...
func innerRequest(client *http.Client, URL string) *ProjectsResponse {
if URL == "" {
return nil
}
//More code...
pagingData := getPageInformation(res)
return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
}
add a comment |
up vote
1
down vote
accepted
I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...
func innerRequest(client *http.Client, URL string) *ProjectsResponse {
if URL == "" {
return nil
}
//More code...
pagingData := getPageInformation(res)
return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
}
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...
func innerRequest(client *http.Client, URL string) *ProjectsResponse {
if URL == "" {
return nil
}
//More code...
pagingData := getPageInformation(res)
return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
}
I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...
func innerRequest(client *http.Client, URL string) *ProjectsResponse {
if URL == "" {
return nil
}
//More code...
pagingData := getPageInformation(res)
return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
}
answered Nov 19 at 23:53
Slotheroo
33018
33018
add a comment |
add a comment |
up vote
1
down vote
The confusion lies in the way a slice
is handled in Go. Here is the in-depth explanation, but I will abbreviate.
The common misconception is that the slice
you pass around is a reference to the slice
, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct
with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.
Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)
Playground link: https://play.golang.org/p/v5XeYpH1VlF
// correct way to return from recursion
func addReturn(s int) int {
if finalCondition(s) {
return s
}
s = append(s, 1)
return addReturn(s)
}
// using a reference
func addReference(s *int) {
if finalCondition(*s) {
return
}
*s = append(*s, 1)
addReference(s)
}
// whatever terminates the recursion
func finalCondition(s int) bool {
if len(s) >= 10 {
return true
}
return false
}
1
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
add a comment |
up vote
1
down vote
The confusion lies in the way a slice
is handled in Go. Here is the in-depth explanation, but I will abbreviate.
The common misconception is that the slice
you pass around is a reference to the slice
, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct
with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.
Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)
Playground link: https://play.golang.org/p/v5XeYpH1VlF
// correct way to return from recursion
func addReturn(s int) int {
if finalCondition(s) {
return s
}
s = append(s, 1)
return addReturn(s)
}
// using a reference
func addReference(s *int) {
if finalCondition(*s) {
return
}
*s = append(*s, 1)
addReference(s)
}
// whatever terminates the recursion
func finalCondition(s int) bool {
if len(s) >= 10 {
return true
}
return false
}
1
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
add a comment |
up vote
1
down vote
up vote
1
down vote
The confusion lies in the way a slice
is handled in Go. Here is the in-depth explanation, but I will abbreviate.
The common misconception is that the slice
you pass around is a reference to the slice
, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct
with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.
Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)
Playground link: https://play.golang.org/p/v5XeYpH1VlF
// correct way to return from recursion
func addReturn(s int) int {
if finalCondition(s) {
return s
}
s = append(s, 1)
return addReturn(s)
}
// using a reference
func addReference(s *int) {
if finalCondition(*s) {
return
}
*s = append(*s, 1)
addReference(s)
}
// whatever terminates the recursion
func finalCondition(s int) bool {
if len(s) >= 10 {
return true
}
return false
}
The confusion lies in the way a slice
is handled in Go. Here is the in-depth explanation, but I will abbreviate.
The common misconception is that the slice
you pass around is a reference to the slice
, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct
with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.
Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)
Playground link: https://play.golang.org/p/v5XeYpH1VlF
// correct way to return from recursion
func addReturn(s int) int {
if finalCondition(s) {
return s
}
s = append(s, 1)
return addReturn(s)
}
// using a reference
func addReference(s *int) {
if finalCondition(*s) {
return
}
*s = append(*s, 1)
addReference(s)
}
// whatever terminates the recursion
func finalCondition(s int) bool {
if len(s) >= 10 {
return true
}
return false
}
edited Nov 19 at 23:26
answered Nov 19 at 22:38
RayfenWindspear
3,5181229
3,5181229
1
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
add a comment |
1
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
1
1
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...
– RayfenWindspear
Nov 19 at 22:53
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1
– Marcote
Nov 20 at 16:30
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.
– RayfenWindspear
Nov 20 at 16:32
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
@Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.
– RayfenWindspear
Nov 21 at 19:11
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53383372%2fproblem-accumulating-appending-values-in-an-array-using-recursion-with-go%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.
– RayfenWindspear
Nov 19 at 22:27
Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)
– Marcote
Nov 19 at 22:34