I was thinking the term has might work better (shorter if nothing else). To keep it consistent:
List.has
Map.hasKey
Str.has
Any votes to make that change?
tacticsFri 2 Oct 2009
I think has sounds weird for List and Str. But containsKey sounds weird for Map as it is today. As long as we don't mind them being different, I'd just change it in the case of Map. But uniformity is a nice thing too.
brianFri 2 Oct 2009
I think they should be uniform since they are all checking if a given value is contained by collection
+1 on changing from contains to has (only because I love shorter names :-)
casperbangFri 2 Oct 2009
I rather like shorter too - I realize contains is de-facto standard in many languages, but I also think it's simply a habit thing easily overcome. +1.
KevinKelleyFri 2 Oct 2009
ehh... +/-1. Shorter's nice; has and contains mean more or less the same thing; but we're used to contains. I just this morning tripped over trying str.length when it's really str.size.
But in Fan we're generally going for the shortest names that don't lose expressiveness, right? So I kinda lean toward +.
qualidafialFri 2 Oct 2009
+1 for short names, but.. -1 for this one. contains implies a composite relationship, whereas has implies ownership. On a UML diagram it's the difference between a hollow diamond and a solid diamond. I'm all for brevity but not if we conflate distinct concepts in the process.
jodastephenFri 2 Oct 2009
This doesn't feel right to me, so I'm -1.
heliumSat 3 Oct 2009
-1
katoxSat 3 Oct 2009
-1, has is shorter but quite uninformative about the operation itself - Str has ... what quality? ahh... it means contains ...
andySat 3 Oct 2009
It sounds like even for people who like it, they don't like it enough to make the change. I prefer Map.hasKey over containsKey - but I certainly like contains everywhere else. So lets keep things as is.
ridcullySat 3 Oct 2009
-1, although Map.hasKey would be ok. But as you write yourself: "they are all checking if a given value is contained by collection" -- so why not use the word contains for this? Perhaps for Map it would be (additionally) possible to have something like Map.keys.contains() or Map.keys().contains() where Map.keys() would be a set of the map's keys.
andy Fri 2 Oct 2009
We've been using the convention
containsfor things that "have" something:sys::List.containssys::Map.containsKeysys::Str.containsI was thinking the term
hasmight work better (shorter if nothing else). To keep it consistent:List.hasMap.hasKeyStr.hasAny votes to make that change?
tactics Fri 2 Oct 2009
I think has sounds weird for
ListandStr. But containsKey sounds weird forMapas it is today. As long as we don't mind them being different, I'd just change it in the case ofMap. But uniformity is a nice thing too.brian Fri 2 Oct 2009
I think they should be uniform since they are all checking if a given value is contained by collection
+1 on changing from
containstohas(only because I love shorter names :-)casperbang Fri 2 Oct 2009
I rather like shorter too - I realize contains is de-facto standard in many languages, but I also think it's simply a habit thing easily overcome. +1.
KevinKelley Fri 2 Oct 2009
ehh... +/-1. Shorter's nice;
hasandcontainsmean more or less the same thing; but we're used tocontains. I just this morning tripped over tryingstr.lengthwhen it's reallystr.size.But in Fan we're generally going for the shortest names that don't lose expressiveness, right? So I kinda lean toward
+.qualidafial Fri 2 Oct 2009
+1 for short names, but.. -1 for this one.
containsimplies a composite relationship, whereashasimplies ownership. On a UML diagram it's the difference between a hollow diamond and a solid diamond. I'm all for brevity but not if we conflate distinct concepts in the process.jodastephen Fri 2 Oct 2009
This doesn't feel right to me, so I'm -1.
helium Sat 3 Oct 2009
-1
katox Sat 3 Oct 2009
-1,
hasis shorter but quite uninformative about the operation itself - Str has ... what quality? ahh... it meanscontains...andy Sat 3 Oct 2009
It sounds like even for people who like it, they don't like it enough to make the change. I prefer
Map.hasKeyovercontainsKey- but I certainly likecontainseverywhere else. So lets keep things as is.ridcully Sat 3 Oct 2009
-1, although
Map.hasKeywould be ok. But as you write yourself: "they are all checking if a given value is contained by collection" -- so why not use the word contains for this? Perhaps forMapit would be (additionally) possible to have something likeMap.keys.contains()orMap.keys().contains()whereMap.keys()would be a set of the map's keys.