[Swift-devel] 'mapped type' terminology

[Michael Wilde]

I agree with this comment. Early on I felt that files should be a 
primitive type - in the language today they show all the attributes of such.

One alternative is to add "file" to the list of atomic types.
Another is to call single files a mapped atomic type.
A third is to find a better name than "mapped type" or "marker".

Can a mapped atomic object be mapped to anything but a file?  Ie, if the 
mapper associates a database or service handle with an object, encoded 
as a string returned by the mapper, when the app is called, wont the 
implementation attempt to locate and pass a file to the application?

(Sorry that this is digressing, but it seems that to name this concept 
we need to make sure we understand its definition)

It seems that its the @filename() designation that causes the current 
file-handling behavior at runtime, and other @something() primitives 
could cause other runtime behavior (such as @handle() for passing the 
opaque mapping or @database() for database-specific passing).

If we did this, then we are essentially expanding the possible set of 
mapped atomic types. One way to do that is to define a tiny set of such 
mapped atomic types. Two that would be useful are:

file == @filename()
data == @data() (for an opaque handle, or @handle)

- Mike


On 1/28/09 8:31 AM, Ben Clifford wrote:
>>From hpdc draft:
> 
>> Types in Swift can be atomic or composite. An atomic type can be either 
>> a primitive type or a mapped type.
> 
> The phrasing of this kinda excludes the idea that composite types might be 
> mapped, which is not true at all...
> 
> The atomic types that are mapped to single files are what I initially 
> called marker types; a better term was sought for that but 'mapped type' 
> is not it in my opinion - being a mapped type or not is orthogonal to the 
> atomic/composite distinction.
>