Old comments broken out from parsedecl.c How to distinguish class/enum/interface and extract filename ------------------------------------------------------------ How Java does it: - classes/records have any names - interfaces end with -able/-ble How C# does it - classes/records have any names - interfaces being with "I" How Pascal does it: - all types begin with T How C does it: - built-in types end with _t Possible options: * Use English-langauge suffixes like Java: -able/-ble = interface -er = class (e.g. FileReader) others = record/struct * Use Pascal/C#-like prefixes: I = interface C = class others = record/struct - problems: needs to handle words start with C, e.g. CssRule * Use case of filename to distinguish: Uppercase.slul - class with name = filename lowercase.slul - mixed no-namespace contents * Use directories: interfaces/... classes/... records/... * Use file extensions: *.if.slul - interfaces *.cl.slul - classes *.rc.slul - records *.slul - mixed no-namespace file Allow putting the full class hierarchy (i.e. incl. subclasses) in a single file? Use filenames for namespacing only and allow LRL-like "here" definitions? Keywords to use? - Want to have the same "kind" of word for all of struct/class/interface. - It's good if they are the same as in other languages. struct record data state class thing object interface abstract Or, use "class" for all, but have keywords for the subtype: unique (but that makes it sound like a singleton) identity interface abstract (maybe even it could work like implicit interfaces?) - can abstract classes of "identity"(like File) and "non-identity"(like Point) appear as base classes at the same time? - when is multiple-inheritance fine? - interfaces are fine, and interfaces have these properties: - multiple-inheritance allowed - cannot be constructed - do not have data - calling super.do_stuff() is not possible in implementing classes - abstract classes: - multiple-inheritance allowed - cannot be constructed - CAN have data, but perhaps require it to be private? (i.e. not accessible by implementors of the interface) - if private, then it should only be accessible from concrete methods... otherwise, it would create a "feature imparity" between default implentations and overridden implementations. - Disallow super.do_stuff(). - Allow three types of methods/functions: - abstract / unimplemented - abstract / with default implementation - concrete and final - concrete classes: - perhaps disallow inheritance from concrete classes (i.e. all concrete classes are final) Simple solution: - have records - have classes (w/o inheritance) - have traits/interfaces More useful types ----------------- - unions/variants/choice - how to make it possible to access (and pass around) the enum value BUT ALSO not have to repeat oneself in the declaration? - perhaps the enum type could be created implicitly. - or it could be some kind of generic type perhaps? e.g. if the tail of classes could be allowed to be a generic parameter. - enums - these could have singleton values, like in Java. Alternative solution with macros(/mixins) ----------------------------------------- - record, class and enum types - Macros for type generation (and usage) of more complex types: - unions (is it possible?) - interfaces (needs macro for access also) Solution with unified classes ----------------------------- - trait Abstract = interface/trait - trait Data = trait Equal,Copy,HashCode,StableCompare = record - perhaps record should provide default impls for equal/copy. - and "trait Data" could - Closed types? - Can runtime type information be avoided? - E.g. in a list of abstract-typed elements. - Want to avoid in-object RTTI - Want to avoid fat pointers (because they would make generic types fat as well) - but could be optimized with a per-generic-object size flag (this could also allow for embedded elements, which would avoid an extra indirection - good!) - would require one size field per generic param. - multiplication factor (to obtain offset) is no longer constant (= it's slower) - could also allow only {1,8,16,32,64,128} bits - could allow for String == List of Byte (or perhaps String.aliased_to_list() and String.aliased_from_list()) - or perhaps skip the aliasing stuff, as long as the String and the List is immutable. - Want to avoid "concretization wrappers" (because of indirection AND because of lifetime / memory alloc) - Reference comparison ability: - same_as operator for all objects? - or trait SameAs? trait Identity? - trait SomeAbstractClass = implements that class - Uppercase filename = implicit class - An initial line with only enum/record = turns Uppercase filename class into an enum/record instead of the default of class Solution with "here" names: - `class file` at start for classes - `record file` at start for records - `trait file` at start for traits/interfaces - `enum file` at start for enums Maybe skip the `file` part? Other necessary attributes: - public/export Nested identifiers/namespaces (e.g. directories) and identifier lookup at the nested levels. - just skip namespacing? it's often more annoying than it helps (as an example, consider all the `import` statements in Java source code, which is often hidden by default in IDE's anyway, and also has a tendency to result in libraries using generic names for things, which makes it impossible to known what a Date or ArrayList is without checking the imports or by mouse-over in the IDE)