if your language had a link type, equality would be over the url? the text? both?

I think both? Just like in a standard PL we sometimes need pointer equality and other times we follow the pointer and the check for equality — entities vs value objects, to use the domain-driven design terminology.

There would be several separate meanings of equality (equal link, equal text), and then a combined product equality. When comparing, pick the equality you need.

I will allow to compare by either when the user is using the data type, my problem is when for example using a link value as a key in a map, there the equality I choose can only be one

What do instances of the link type denote? Do they denote the file that the URL points to, or do they denote the link itself? What operations are available on link values? Do these operations operate on the contents of the file, or do they operate on the URL? If I print a link value to the console, will I see the contents of the file, or will I see the URL? In the former case, equality should be defined on the file contents. In the latter case, equality should be defined on the URL. What you see when you print a value is a strong hint about how equality should be defined for that value. In Curv, I have a 'file' function that takes a URL as an argument, and returns the contents of the file. If I want URL equality, I use 'url1 == url2'. If I want file equality, I use 'file url1 == file url2'.

it's a web based application, can't link to files. The object is a link, it's the value itself and the operations operate on the link, I can't operate on the content of the url (I could have an operation to fetch the content if I wanted), can't print to the console, can only display it, if displaying it it will display itself, I could have a function to transform it into an iframe if it made sense.

How about

Link

only checking for URL equality (that’s what I would expect from a dedicated

Link

class or type) and offering a

.toString()

method or something like that to make it super easy to drop down into

String

and its comparison behavior. Leaving some control over what is wanted to the developer seems better than having “magic” behavior that will end up as surprising and unwanted in some cases. Your http/s example sounds like you might want to offer easy ways to get to parts of the URL (scheme, host, path + components, query) as well so people can easily combine the parts they care for when caching. I’d say http and https are different URLs and treating them the same is asking for trouble, but with easy access to just the host and path you can build a straightforward cache without any confusion.

@Stefan I find the comparisson by url to be the most common sense one, but not as common sense as when I did the first aggregation and the MIT links where not aggregating together and I went on a quest to find why equality was broken on my system before noticing that they all pointed to a different url (something that is not immediatly visible, only hovering over two or more links with the same label may make you notice it)

@Mariano Guerra It does certainly show how tiny little details make our jobs so complex: so many choices to make, so many expectations to break, so many things to be opinionated about…

yep, the one that's common sense tripped me at the first attempt to use it 😄

FWIW, it's not uncommon for a data type to contain both canonical and non-canonical instances, but there to be a run-time method to canonicalize and data structures that canonicalize on the way in. Types for file paths usually work that way, as do shapes like rectangles where there are multiple equivalent representations. Also, for URLs, probably the best way to canonicalize is to look for https://en.wikipedia.org/wiki/Canonical_link_element