Handling of Primitive Concepts
Brought to you by:
han_joosten,
oblosys
'Primitive concepts' are concepts for 'primitive types'. Examples are 'TEXT', 'BLOB', 'INTEGER', 'DATE', 'EMAIL' etc. There does not seem to be a need to have an atom table for such primitive types, and for certain there are no 'wide tables' that have such atoms as a key. Therefore, we can do without tables for primitive types. This saves a considerable amount of database queries in cases where many atoms of primitive concepts are used. This would speed up transaction handling in cases where such primitive types are used.
Note that primitive concepts are currently introduced already, because the (new) frontend needs to know them because they need to be treated specifically in the frontend.
In the discussion in ticket #452 Martijn states the difference between the support for primitive concepts (in Ampersand) and the presentation of these primitive concepts in HTML. What do you think of the following approach:
Let me know what you think of the above.
There's basically three issues being discussed here: the names of our primitives, how they are handled at the database level, and how we specify their presentation.
About the names, I think BOOL is much better than BOOLEAN, but I'm not a fan in general of W3C's overly verbose standards. Then again, I don't know much about frameworks we might communicate with, and how much it would benefit to have exactly the same primitives.
I'm also not a fan of shouting primitive concepts in capitals. Since the 1980's, most programming languages moved away from capitalized primitive types. People have no problems understanding that some concepts/types are primitive, even when not reminded by capitalization. Also, since in Ampersand you can declare non-primitive concepts with capitalized names, a capitalized name would not even guarantee a primitive type. Is there a strong reason to enforce these capitals? Simply using
String
,Date
, etc. will also maintain a visual distinction between concepts and Ampersand keywords.Having a special treatment for primitive concepts at the database level sounds like a good idea. I believe something like this is currently happening for blobs, although it may not have been implemented completely.
Concerning the presentation, if we use the target concept for this, the presentation of a context will be encoded in the model, which is not a good idea. We could work around this by composing with an appropriate
I
in the interface. For example, if we have a functionisAccepted[Order*Bool]
which is to presented as a switch, we could writeHowever, in this case
Switch
needs to be a generalization ofBool
, rather than the other way round. It will work, but it is not a very elegant solution.Another issue with using the target concept to select the template is that it inconsistent with the situation for boxes, for which we use the class. Also, we may want to have specialized presentations also for non-primitive concepts, which points us in the direction of views. (Simply using the target concept to select a template will not suffice, since we will also need to specify some relations to present the raw atom ids)
I have a couple of ideas about integrating the VIEW mechanism with the new front-end templates, for which I will create a GitHub issue.