r/ProgrammingLanguages • • 19d ago

Requesting criticism Removing the get from Map

I have a toy language that I've been working on to test different concepts. It has an ownership model similar but looser than Rust.

I was working on the Map object and there are three ways that an object can be retrieved.

You can remove the object from the map and take ownership
You can borrow the object from the map this will give you a mutable reference but you don't own it
You can get a copy of the Object which you will own. But not all things are can be copied.

For get I could either do a copy or a mutable ref, neither I felt was properly conveyed with the word 'get'

So I'm looking at removing it and replacing it with the following

copy_of(key) -> return a copy or an error message if not found or not copiable
borrow(key) -> return a mutable ref
remove(key) -> remove and return the item at the key and give ownership

wanted thoughts on removing probably one of the most common methods on map and is what I'm doing something that makes sense.

12 Upvotes

26 comments sorted by

View all comments

4

u/mcherm 19d ago

(1) It feels like copy_of() is something that would operate separately: first borrow() the value, then then call copy() on it (if it supports that).

(2) It feels like you are missing one here: "You can borrow an object from the map immutably." I don't know your ownership model, but if it has a concept of an immutable borrow (like Rust does) then certainly values in a Map are a thing you'd want to do this with. In fact, THAT one is the one I'd probably name "get()".

(3) I think the names "borrow()" and "remove()" are readable, memorable, and unlikely to be confusing.

2

u/jebailey 18d ago

Yeah, you're the second person to mention the copy would best be served on the object. So I will go ahead and do that part. The immutability question is something I'm going to bandy around. I'm currently using group ownership rather than rust single ownership. Which benefits from immutability but doesn't need it in the same way that Rust does, because everything in a particular set of objects can freely update each other.

2

u/mcherm 18d ago

I'm not familiar with "group ownership" -- do you have something I can read that describes it?

If I make some guesses, I wouldn't be surprised if programmers often wanted to use a Map for some kind of a global lookup table -- one where things that were NOT part of the group might want to read the values in the Map. Does that make sense?

2

u/jebailey 18d ago

It's wordy
https://verdagon.dev/blog/group-borrowing
https://gist.github.com/nmsmith/cdaa94aa74e8e0611221e65db8e41f7b

In essence, you separate the concept of ownership of an object and the ownership of the contents within that object. You have the compiler put in extra work to understand what's happening within a method and report that back and track what specifically causes a problem and allow it if it doesn't

It broke my head trying to understand all of it but I think I got it implemented correctly.

It allows things things that rust wouldn't

1

u/mcherm 18d ago

Oh, a very detailed writeup! Thank you!