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

block.resize must return itself instead of true #3540

Closed
yegor256 opened this issue Nov 24, 2024 · 4 comments · Fixed by #3548
Closed

block.resize must return itself instead of true #3540

yegor256 opened this issue Nov 24, 2024 · 4 comments · Fixed by #3548
Assignees

Comments

@yegor256
Copy link
Member

Currently, the block in malloc returns true on resize. It doesn't make much sense and is not helpful. I suggest it to return itself (the block).

@yegor256
Copy link
Member Author

@maxonfjvipon WDYT? Any objections?

@maxonfjvipon
Copy link
Member

@yegor256 no. It also it should be renamed to resized

@maxonfjvipon
Copy link
Member

maxonfjvipon commented Nov 25, 2024

@yegor256 I'm trying to implement resized object and I faced an interesting situation. The piece of code in malloc-tests looks like: (m.resized 6).size.eq 6.

Here I'm resizing block and trying to get the size of it.
But I noticed that block is not being resized and here's why:

[id] > allocated
  [] > size
  [size] > resized /allocated

Here resized object has attribute size and allocated object has attribute size. When I write (m.resized 6).size.eq 6 I assume that I take allocated.size object after it's resized. But I just got allocated.resized.size attribute because it's closer than allocated.resized.λ.sized

WDYT about such case? Is there a way we can prevent or predict such situations because they're quite confusing for unprepared developers

maxonfjvipon added a commit to maxonfjvipon/eo that referenced this issue Nov 25, 2024
yegor256 added a commit that referenced this issue Nov 25, 2024
@yegor256
Copy link
Member Author

@maxonfjvipon we can prevent this with the help of a new linter (maybe this one: objectionary/lints#21)

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

Successfully merging a pull request may close this issue.

2 participants