Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code review: TyphoonGenericStack #81

Closed
jasperblues opened this issue Sep 13, 2013 · 10 comments
Closed

Code review: TyphoonGenericStack #81

jasperblues opened this issue Sep 13, 2013 · 10 comments
Labels

Comments

@jasperblues
Copy link
Member

@cesteban

  • (id)pop
    {
    id element = [_storage lastObject];

    [_storage removeLastObject]; <----- This can cause array index out of bounds, wrap in if.
    return element;
    }

@cesteban
Copy link
Contributor

You are right. This out of bounds would never happen in the context of Typhoon stash, but this is a generic stack. I'll address this along with the concurrent issue.

@jasperblues
Copy link
Member Author

I was just being (unnecessarily) pedantic ;)

Still - we might as well make it generic, since its only a one line change.

@cesteban
Copy link
Contributor

Don't worry, that wasn't pedantic. The class is named GenericStack, so popping when empty must be supported and properly handled. I'm changing this.

@cesteban
Copy link
Contributor

I made "failing" test for this, and it happens that when calling removeLastObject for empty array, no exception is thrown! From Apple documentation: removeLastObject raises an NSRangeException if there are no objects in the array..

I found this stack overflow discussion: http://stackoverflow.com/questions/14760542/nsmutablearray-removelastobject-exception

I protected the stack anyway, just in case. Should I directly push the changes, or do you prefer me to branch and pull request? It is one line of code and one added test.

@jasperblues
Copy link
Member Author

I trust the quality of your work 100% - you've been allocated push access.

@jasperblues
Copy link
Member Author

Also, feel free to push anytime. The general rules are:

Any experimental/controversial/long-running feature should be done on a branch, because:

  • This kind of work might not be finished before someone else commits a useful feature. So would hold up a release.
  • Experimental work might need to be rolled back, if we discover something that "ain't gonna fly".

Having said that, we practice 'continuous integration', so the sooner it goes to master the better. If it exposes a problem, we'll know about this early and deal with it. . . use your judgement to balance these concerns.

Any other work can go straight to master.

Don't be shy ;)

@cesteban
Copy link
Contributor

Ok, thanks. I generally don't like pushing to master, but this is a pretty obvious one liner, so we should be safe.

@jasperblues
Copy link
Member Author

Ok - whatever you prefer. I you want, you push you have access. Pull requests are also fine.

In any case - I really appreciate your contributions and feedback. They've been useful for my work, as well as for other Typhoon users, I'm sure.

@cesteban
Copy link
Contributor

Thanks a lot, but I just did a few fixes, nothing really important ;)

@jasperblues
Copy link
Member Author

What did I write above!?!? I meant to write:

"If you want, you have push access. Pull requests are also fine".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants