[swift-evolution] [Pitch] Rename Mirror

Dmitri Gribenko gribozavr at gmail.com
Thu Jul 21 18:39:47 CDT 2016


On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:
> 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.

I understand.  But we don't know how reflection will work in Swift, we
haven't designed it yet.  You are assuming it will work like it does
in other languages, which will not necessarily be the case.

> 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.

That is actually viewed as a weakness of reflection in other
languages.  Allowing reflection to access other types' internal data
and APIs creates barriers for optimization, and facilitates creating
binary compatibility problems when apps include code that uses
reflection to poke at internal data of library types.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/


More information about the swift-evolution mailing list