Sugar naming conventions

Elements Elements RTL
1

Browsed sugar on github for the first time today and I like where it is headed except for some naming conventions.

The mapped class names are not distinguished from the underlying platform classes’ names: Sugar’s String is mapped to System.String and java.lang.String for example. Given that the underlying platform type will often be present in the same context as the Sugar type, I believe it is a mistake to have them share the same name. Adopting a simple and low-overhead naming convention such as prefixing an O (OString), would provide a great deal more confidence to me personally when I’m reading code.

Perhaps I am underestimating some of the advantages of the current scheme though?

2

this was done mostly intentional, especially for the likes of String. because Sugar.String will cast toll-free to the system string types, all you need to do is have Sugar in your uses clause, and any “String” you define will be a sugar string — but still be seamlessly passable into any system APIs.