add review_positron.md - conatins positrons feedback based on the IRC-log of today.

review_positron.md

@@ -0,0 +1,81 @@
+# Review Positron
+
+## Explicit Integer Sizes
+
+Last week at fdik's we spoke about mapping IDL type to language types; and we found it desirable to specify explicit
+integer sizes for some languages -- for example Java, that mandates a precise size for int and long.
+Shall we do the same for C and switch to stdint types? I would say not, because it is not in the “culture” of C.
+But, if we want to follow the minimum-common-denominator idea, maybe we should not have any unsigned type.
+I am willing to remove them from the Engine API if we agree on that.
+
+## Terminology: Param Passing Mode
+
+fdik is not very happy with the mode names
+And yes, he has a big point
+about them not conveying an explicit idea of ownership.
+Agreed: we can easily rename them later
+
+## Bitmasks
+
+e.g. flags
+Personally I would use unsigned integers only for bit masks -- well, we have them :-)
+Those could be made unsigned, but in practice I think we do not care. We can assume that ints will have at least 31
+non-sign bits on every configuration
+
+## Optionals
+
+In C and C++ passing objects by pointers also allows representing NULL values. That is also true in most languages but
+not in all. And I think that we do exploit the NULL case in some functions; certainly for strings.
+Have we got “optional output parameters”? Those are used in C. Something like: if the 2nd parameter is not NULL, the
+function will set the pointed variable to X, otherwise it will ignore it.
+Do we want to remove that from the API? That will be difficult to map in different languages.
+So, in the document we seem to really rely on the possibility of pointers being NULL. Type definitions might be a little
+messiers in languages where that is not allowed by default. Rust is probably one of those.
+I do not really know Rust but know ML and Haskell. To present the problem, this is what they do:
+I can use ML as an example.
+For every type “T” there exists a type “T option”.
+There is no NULL in the language, and no implicit initial value for variables: it is mandated by the syntax that
+variables are initialised.
+So, how do we represent “absent” values?
+“T option” has two kind of values: “Nothing” or “Some V” where V is a value of type T.
+So, we rely on pointers being used both for indirection and for optionality.
+The point is: given a struct definition, we usually want its non-primitively-typed field to be optional.
+That is certainly the case for identities and messages.
+AGREED In theory we should accept that a lot of that work is done “by hand” by the person who writes the adapter,
+because the native type definition is supposed to follow the language culture
+
+## Binary
+
+I do not think that “binary” can be mapped to “char*”. We need a size as well.
+And I would make the char explicitly unsigned.
+
+## Terminology: Allocation
+
+Instead of “Primitive types are always statically allocated” I would say “objects of primitive types do not require heap
+allocation”.
+Well, I would not speak about static allocation
+In a bizarre implementation where such object do not live in registers, they will live on the stack.
+Maybe on a 16-bit machine, for example
+Yes. I would say “not heap-allocated”.
+Even if it were allocated dynamically it would be an “easy” way of allocating and destroying: completely LIFO
+We are speaking of “automatic variables”. Does the C speak speaks of “automatic storage”?
+So, the Standard speaks of “automatic storage duration” and “temporary lifetime”.
+I think that for primitive types we want “automatic storage duration” (always) and “temporary lifetime” (usually)
+
+About allocators, in a high-level API I would personally be happier if it were *not* possible to allocate empty objects,
+but only minimal already valid objects. For example an identity with all fields NULL is effectively useless. Shall every
+object type have an allocator? Notice that strings do not really have that.
+
+## Ambiguity of T
+
+In the document “*T” (different from “T*”) refers to a C type, not expressible in the IDL language, which is the
+translation of T into C dereferenced once. Nice: “*T” is used consistently in the document. But I would define it
+explicitly.
+Maybe we can be more precise about T and “the translation of T into the language” without being too verbose
+theoreticians like to use “fat brackets” for this
+Here they are: 〚 〛
+So, we could say T and 〚T〛
+
+
+
+