Skip to content

Conversation

@clownpriest
Copy link
Contributor

so you can set a value without growing the underlying buffer (like
insert function), maybe better than working directly with self.items

so you can set a value without growing the underlying buffer (like
insert function), maybe better than working directly with self.items
@BraedonWooding
Copy link
Contributor

Thanks for opening a PR :)! A few things however,

Since you don't actually increase the .len field in the structure when iterating (using the iterator) through it you won't actually iterator across the items you set. Maybe perhaps you meant to compare against the n > self.len which would guarantee that you are only accessing the current 'array'? Since going outside that is really against the idea of an array list. If you want to set items anywhere in that internal array you are right probably better to go with self.items directly as that is more explicit.

Also l should be called self by convention.

@clownpriest
Copy link
Contributor Author

i used "l" rather than "self" just because all the other function currently use "l". latest commit compares bounds with l.len rather than items.len. i'm fine to close this PR and just set explicitly through self.items[], though then the caller would have to worry about iterators and self.len, no? maybe it's a non-issue

@BraedonWooding
Copy link
Contributor

BraedonWooding commented Jun 7, 2018

Oh you are right, those should probably be changed since some of them are self (only a few) and some are l huh fair enough (atleast one or the other) but that's something separate.

Anyways, I think this is useful enough since it does bound check it against the current 'array' but we'll see what others think :).

@thejoshwolfe
Copy link
Contributor

Please add a test for your new api.

Adding tests would help catch bugs like the one @BraedonWooding pointed out. Tests are also a nice way to document the usage of your code. In general tests are good to have and will make your code easier to review and more attractive to merge.

@clownpriest
Copy link
Contributor Author

thank you for the recommendation! found a bug in the process of adding tests. latest commit has tests and the bug fix

@BraedonWooding
Copy link
Contributor

BraedonWooding commented Jun 9, 2018

@clownpriest Note: sometimes travis errors out like this, often it'll work when re-run (note: how under the details for travis-ci/pr it says it '!' error'd, it didn't say it failed), you can force a re-run by closing PR and reopening it or someone with admin rights I think can re-run it :).


list.set(9, 99) catch |err| {
assert(err == error.OutOfBounds);
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error checking is not correct. It should be more like:

if (list.set(9, 99)) {
    assert(false);
} else |err| {
    assert(err == error.OutOfBound);
}

This is such a common pattern that there should probably be a convenience function in std.debug for it. 🤔

Copy link
Member

@andrewrk andrewrk Jun 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would generally recommend @panic("assertion failed") over assert(false).

@andrewrk
Copy link
Member

andrewrk commented Jun 9, 2018

merged in e0092ee

@andrewrk andrewrk closed this Jun 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

None yet

4 participants