[swift-evolution] [Pitch] Rename Mirror

[Dmitri Gribenko]

On Thu, Jul 21, 2016 at 4:49 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:
> 2016-07-22 2:39 GMT+03:00 Dmitri Gribenko <gribozavr at gmail.com>:
>>
>> On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin <antonyzhilin at gmail.com>
>> wrote:
>> > 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.
>
>
> I talked about Swift here.

I am also talking about Swift.  If we build a reflection mechanism
that would allow third party code to poke at Array or Dictionary
implementation details (or any other type for that matter), we would
be exposing us to the same pitfalls as other languages have now.  I
would be opposed to doing that.

> Types can completely customize contents of their
> Mirrors in Swift.

This is desirable, for implementation hiding reasons.  Nobody should
be able to observe implementation details of Array, Dictionary, or any
other library types through programmatic mechanisms.

> A type, which pretends to be used for reflection, can't
> afford that.

Why not?

You see, we (as a community) don't have a shared long-term vision
about what "reflection" means.  Establishing that agreement would be
the prerequisite to starting any formal proposal process.
Speculatively making changes based on hypothetical designs that were
not discussed yet will not bring us to a better place.

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>*/