[swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen]

> On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Reflection is likely to be tackled in Swift 5, no?

I'd think you don’t need reflection that much, because defining
dynamic classes (and other entities) are solely incremental compiler
tasks, for which it can use  previously compiled meta reference
information (xref symbols etc). 

Imho in that perspective it is more or less independent
of reflection. Reflection is as far as I can see is more intended to offer 
meta information at the programming level.? 

> So realistically, this could be on track for Swift 6 or 7.

As already written, there is no timeframe/deadline for this idea, it is just an idea, 
not a proposal (yet).

> Let's postpone discussion until then.

Feel free to do so, but why postponing having ideas and discussing them? 
In this case for instance, thinking about dynamic facilities, will presumably 
also influence thinking about reflection and vice versa. 
Thinking “wider” and “further” broadens the horizon of course.
For example. what about a compiler/interpreter self improving based on artificial intelligence? is this 2016? 
So one can (should) do both: that is think in small steps, like discussing
“just”  language elements and at the same time have an eye (or two) for the 
broader picture. If one concentrates too much on the direct path in front, one might
not see other paths or what lays further ahead, which limits progress. 

————————————————
Let me write a small cartoon here, just intended as a little bit of humour just to illustrate this:

A few thousand years ago, two very nice beings ( just returned from attending a
very primitive and awkward election debate, still shivering),  looking at a pair 
of fairly round stone slabs with a hole in the centre.

“What’s this ?, Why round? why the holes? Nice job, but what is it? Is it art?”

“Errrrhmm, well.. I might call it ‘Wheelz', not sure yet, you can use two of more of them
underneath or aside of things you’d like to move around more easily…
with less friction, which was a hell of a drag anyway."

The other guy walks around it, apparently deeply thinking about it. 
after some silence he says:
“Aha… hmm.. well.. Oh, i see, yeah, yep, that’s kinda cool.. might be useful. 
But let’’s postpone discussing it until  ball-bearings have been invented. “
————————————————

hmmm, I really have too much time… :o)

Kind Regards
Ted



 






> 
> 
> On Tue, Oct 11, 2016 at 15:59 David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Hello Ted,
>> First of all, this topic belongs to reflection, which is specifically stated to be out of scope of Swift 4 Phase 1. So all considerations are purely theoretical for now.
>> That said, I also thought about this problem. The best I could imagine is something along the following lines:
>> 
>> var builder = StructBuilder(name: "Person")
>> builder.addProperty(name: "name", type: String.self)
>> builder.addProperty(name: "age", type: Int.self)
>> builder.addComputedProperty(name: "description", getter: { (this: Any) -> String in ... })
>> builder.addComformance(CustomStringConvertible.self)
>> let type: Any.Type = builder.build()
>> Obviously, to interact with such dynamic types and their objects, we need the whole working reflection system that we don’t have right now.
>> 
> 
> I *think* that's only true for non-generic code, and types that aren't subclasses... I think...
> 
> Anyway, I'm starting to wonder if some code I'm trying to write might be impossible without either this feature, or some/all of the stuff from the generics manifesto. So put me down as, in principle, a strong +1 (pending details of the proposal when it actually gets written for Swift 10).
> 
> - Dave Sweeris 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161012/9b993249/attachment.html>