Classifies names according to case, uses for filename generation.

[gspencergoog]

Currently, when you generate docs for dartdoc itself, there are some symbols (from the args package, but they could be from anywhere) where there are metamers of those symbols: When dartdoc generates the filenames, it generates the same name with different case. This is fine on Linux, where filenames are case sensitive, but on macOS and Windows, which are case preserving, but case insensitive, they map to the same file. So, once you check it in to git, you can't sync that repo to macOS or Windows without git complaining that one or the other of the files are modified.

This fixes that problem by classifying types as having different capitalization (camel case, upper case, lower case, lower camel case), and using those in the filenames. The default is CamelCase, so no identifier is added to symbols with camel case names, but others get -upper, -lower, -lowerCamel, or -camel, depending on their type. Each kind of symbol has a "case default" that is implied and not appended if the name matches that case. For instance, a class using camel case, or a method using lower camel case would not have any suffix. In addition, it will only add a suffix if there are metamers in the first place.

For cases that don't fall into those (for instance theUI and theUi are both lowerCamel, but they would have the same filename on a case-insensitive filesystem), it appends a set of numbers that represent the case runs (the number of consecutive letters with the same case) in the name (for instance theUi would have -lowerCamel-0311 appended, but theUI would have -lowerCamel-32 added to make them unique).

Addresses #1196

[jcollins-g]

I don't see where writtenFiles is being populated with lowercase names.

also nit: once it is, this case is actually the union of the previous case and the metamer case.

[gspencergoog]

It's populated in the .map() in this expression. I can't just populate writtenFiles with lowercase names from the start, because on Linux it would be incorrect because it's case sensitive, and would be looking for the wrong file in the allowOverwrite case.

[jcollins-g]

Oh, right. That's likely to be really slow, as we'll convert the entire set every time, but yes it will work.

[gspencergoog]

Yeah, I think I'll just make two lists (one actual case, and one lowercase) to make it more efficient.

[jcollins-g]

What's going on here? I wouldn't have expected this one to shift.

[gspencergoog]

I think because constants have a default case of "UPPER", it names it this way. It shouldn't be doing it unless there is a conflict, however. I'll check into it.

[jcollins-g]

What motivated this? IIUC, interfaces/mixins/supertypes and so on should be picked up by the libraries that contain them, and also not be relevant to the library containing the class they reference.

[gspencergoog]

Huh. Yeah, I guess you're right. I had that in there before I was making sure to add all the names from the model elements in the library, so maybe that was just redundant.

[jcollins-g]

I think only canonical ModelElements are likely to be relevant here, as those are the only ones we will ever generate links to. However, doing all ModelElements the same might simplify matters so OK to leave this if it does.

[jcollins-g]

Also, this is literally all modelElements for the library, including nested members of classes, parameters, and so on that will never be written into the same directory. That might cause "collisions" that aren't real.

[jcollins-g]

nit: braces for multiline if

[jcollins-g]

nit: typical dartdoc style is to build the cached item as part of the getter wrapping a variable. For private members, this can look something like:

Thingy __theThing;
Thingy get _theThing {
  if (__theThing == null) {
    _theThing = new Thingy(doSomeStuff());
  }
  return _theThing;
}

Not super strict on it, but it would be nice for readability to make this consistent.

[gspencergoog]

I can't quite get there, because it needs to supply an argument that isn't always the name. (a unique dirName for libraries is also found using this function).

[gspencergoog]

This was an ambitious project, and it almost works, but it's a year out of date now, and would probably be a nightmare to merge, so I'm going to abandon it for now.