> On Jul 21, 2016, at 4:06 PM, Anton Zhilin via swift-evolution > <swift-evolution@swift.org> wrote: > > 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko <griboz...@gmail.com > <mailto: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. > '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.
I think pointing a Mirror at a metatype value could be a good a mechanism for getting information about the type's stored properties and other members. FWIW Mirrors are inspired by a feature of the same name in the Self language, which made reflection somewhat more principled than the disorganized APIs you see in Java and C#. Perhaps the latter are not a good model to follow here :-) Slava
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution