> 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

Reply via email to