[swift-evolution] [Pitch] Rename Mirror

[Thorsten Seitz]

> Am 22.07.2016 um 01:06 schrieb Anton Zhilin via swift-evolution <swift-evolution at swift.org>:
> 
> 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko <gribozavr at gmail.com>:
>> 
>> > Mirror.DisplayStyle contains optional and set as special cases, but does not
>> > contain function
>> > Mirror collects all information possible at initialization, while for true
>> > reflection we want laziness
>> > Mirror allows customization. For example, Array<T> is represented with a
>> > field for each of its elements. Do we want this for “true” reflection we
>> > want to add in the future?
>> 
>> Why can't we add these features to Mirror in future?
> 
> Reflection in some other languages works as follows: we have a type (let's name it 'Reflection'). Each instance of it contains ID of one type and can, for example, retrieve an array of its static or normal methods.
> 'Mirror', on the other hand, serves as a container for information about a single instance. Moreover, types can completely customize contents of their 'Mirror's. This is incompatible with laziness and with how reflection should work, based on experience from other languages.

Actually mirror based reflection has a couple of advantages like decoupling the reflection API from the normal API and being able to provide different mirrors for different purposes. See the paper of Gilad Bracha who used mirror based reflection in Newspeak and introduced it for Dart:

http://stackoverflow.com/questions/12132264/what-is-the-difference-between-mirror-based-reflection-and-traditional-reflection

http://bracha.org/mirrors.pdf

Abstract of the paper: "We identify three design principles for reflection and metaprogramming facilities in object oriented programming languages.  Encapsulation: meta-level facilities must encapsulate their implementation. Stratification: meta-level facilities must be separated from base-level functionality.  Ontological correspondence: the ontology of meta-level facilities should correspond to the ontology of the language they manipulate. Traditional/mainstream reflective architectures do not follow these precepts. In contrast, reflective APIs built around the concept of mirrors are characterized by adherence to these three principles."

-Thorsten 

> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160801/41aad7a3/attachment.html>