-
Notifications
You must be signed in to change notification settings - Fork 55
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
Problem with map auto initialization #170
Comments
@skejeton I cannot agree with you on this point. What you call an auto initialization is a widely accepted approach. C++'s Maps in Go are more elaborate, as they return a valid (zero, not In Umka, you can always check if the key exists by calling Regarding your proposals:
|
Hi I think it's worth to take a closer look at this issue. I think the mistake Go designers made should be learned from.
I don't think it's impossible, you can easily track if there's any accessible references to the item, and if there is, pass it up. If there's a single reference from the map itself (and the element wasn't assigned to), then you can free it without any problem. Unless I'm misunderstanding something.
It's arguable if it's confusing or not, if the user would use the returned value as a temporary (or copied) variable, they would have to dereference it. However this is except for the case when it's a struct or an array, in which case accessing it's members is indistinguishable from pointers/values. Either way this is as simple as doing
It's a good point. I never viewed it that way, I just assumed []= and [] are different operations with no intersect. In my opinion though humans are heuristic creatures so trying to make a strictly logical thing might be less preferred over a shortcut solution. (after all, that's the rationale to why I think good syntax is nice, even if it's extra edge cases and complexity) I'll leave this issue for later, when I make more use of maps and have a better understanding of them in a more practical manner, so as for now, this issue could be last on the list. It's also reminder for me to remember it's a scripting language so it should be designed for convenience, but there's many ways to solve that, with different drawbacks. |
@skejeton You convinced me to reopen it and continue discussion, though I'm not planning any immediate actions here.
Right. In Umka I have perform essentially the same trick, as I have no
|
Sure, and thank you. I'll be sure to report anything I find interesting about this.
And I think this may be just solved using the first method (which is luckily an implementation detail, so no code has to be changed). It should be a win-win even if difficult to execute. And indeed, don't hurry, and take your time, prioritize what's easier first. Take my issues with a grain of salt and better instead close them later as resolved or unplanned to have a better overall picture 👍 |
I know this is mostly for Go parity, however this creates big problems when you access a map with a large value type that's gonna just sit around because it was never meant to be created.
I was converting my old code that used old maps, which returned pointers, and so I assumed the same semantics.
Now what's wrong here? Well my code worked as expected: I checked if chunk was null and returned zero. Except that branch never executes, instead it created a chunk I didn't want to be created, and wasted some RAM, but it still works as it coincides with zeroinit.
The first place I've actually encountered this as problematic is here:
The code that is responsible for creating the image is never executed. Thankfully due to tophat's logs it didn't take me long to figure out why text wasn't rendering, the image indices were 0. Although it did take me a while to realize the image.Image struct was initialized to 0 because of auto init (or rather that auto-init was a thing).
There's few approaches I can think of:
e.g. if we did
some_map["test"]
and it created and returned default zero initialized value,It would free that value at some point by the garbage collector.
Drawback: If the key is periodically accessed it might mean allocating/freeing all the time, not a big deal though because if solved correctly, these periodic accesses should be rare and thus not have any noticeable performance impact.
Drawback: Obviously maps will not be able to return values, but whether that's a good or a bad thing is debatable.
&some_map["test"]
it will not create a value, but instead return null if it doesn't exist.Drawback: This might be a bit inconsistent and confusing at first to people unfamiliar
This is open to discussion, I don't actually have critical problems with RAM usage. But the auto initialization (and maybe, accessing by value) might be a dangerous trope.
I'm not a Go developer, I don't know it beyond the basics, nor do I have any experience with it. I'm mostly with C and C++ background, so it might be unsubstantiated for me to complain.
The text was updated successfully, but these errors were encountered: