Why the transformation of dots and dashes in shape type -> file name?

[Piedone]

If you have a shape type with an underscore ("_") then the corresponding template file will have a dot (".") there. Similarly, a double underscore in the shape type will translate into a dash ("-") in the file name. It recently occurred to me that I don't see why this conversion is necessary, apart from "it used to be like this in O1".

In O1 this kind of had a technical reason: Shape types were also used in Placement.info files in XML attributes. It seems to me that technically using dots there would still be legal but certainly weird.

I don't see any technical reason in OC though. Everywhere where shape types are used they're just strings so they can contain anything. File names are the lowest common denominator but the affected characters wouldn't cause any issue there either. Not using underscores in cshtml file names is probably a C# convention but why not use dots and dashes in the string shape types too then?

[ns8482e]

I think its because compiler also converts cshtml to compiled class in similar fashion

[Piedone]

Probably, but that doesn't really make it necessary everywhere else I think.

[sebastienros]

The shape type is not a filename. The shape type doesn't have to deal with what chars the FS can support, where the file is/ The way files are converted to shape and shape templates is an implementation details. Shape templates can come from many sources, and even the folder name (Parts, Editors, ...) might impact the shape type.

Could have shape types been modeled using a filename in mind?
Maybe, but there is some logic to convert filenames into shapes even within the string itselft, like Foo_Summary__Bar is actually Foo-Bar.Summary.cshtml. The way shape types are represented and extended doesn't match how filenames should be defined. Foo-Bar.Summary.cshtml, Foo-Bar.Detail.cshtml is better than Foo.Detail-Bar.cshtml and Foo.Summary-Bar.cshtml.

The type's components might also contain - or .. Then it's the responsibility of the Shape harvester to find ways to map filenames to a shape type, not to the Shape subsystem to be sure it will work on a filesystem.

Is it overengineered?
Maybe. I might miss some reasons since I wasn't part of the team who designed it. But I trust their decision, there might be other reasons that are not obvious for us.

NB:
You can create a custom shape harvester that would look for files that match exactly the a shape type. This is what we do with the admin templates.

[Piedone]

Yeah, sometimes file names don't match the pattern of shape types (which I also find confusing) but the conversions . -> _ and - -> __ are consistent throughout and I don't see why they're necessary (I don't see a technical reason, nor why it would be nicer but it's one more thing to know about). This particular aspect seems to be a leftover.

[jtkech]

I thought about dynamic property accessors

Shapes are also used as root properties in placement json files but that's okay as in the code we don't use property accessors for them, only for their well known child properties

But with the dynamic shape factory New.Foo__Bar() works but New.Foo-Bar() would not

[Piedone]

Good point! Though we could just use underscores in file names too.

[ns8482e]

What I learned so far from shape system is that _ is used to identify DisplayType and you can have only one _ (immediately after actual shape type) But you can have more than one __ that could represent variations of ShapeType Or Property shapes