On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin <antonyzhi...@gmail.com> wrote:
> 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko <griboz...@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 <griboz...@gmail.com>*/
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
