That's far more interesting than lasagna recipes :-) More abstractly, if I understand correctly, you want to write some code, which in turn will — at runtime — write its own code, *and* said code should have the ability to interact with the already-written code. Does that sound like an accurate summarization?
If so, I *think* what you're asking for can, in effect, already be accomplished by restructuring your code (if necessary), requiring a swift toolchain to be installed (already done if this is for a personal project), and using the dylib mechanisms to compile and call the "2nd generation" code at runtime. The part I'm unsure of is how to make a module map for the "1st-gen" code to link to when the module doesn't actually exist yet... If you're on macOS*, it might be easy(er) to write a "discovery" API layer in Obj-C which exploits its dynamism to pass the details on the "2nd-gen" code back to Swift land. I'd imagine it'd all have to be done with a ton of generics programming and a library containing all the protocols, base classes, and such that the two code bases would need to talk to each other (at least it could be a normal, run-of-the-mill statically linked library). I kinda hope I'm missing something and there's more to it than that, though. I find your idea quite intriguing, and I'd be a little bit disappointed if it turned out that something as "out there" as dynamically-named variables could be effectively, if not literally, reduced to just a DLL and some compiler trickery. - Dave Sweeris *I know there's something about Obj-C interoperability that's very specifically only part of the Apple ecosystem and isn't part of open-source Swift, but I can't remember what it is. Sent from my iPhone > On Sep 4, 2016, at 11:43, Fayez Hellani <[email protected]> wrote: > > And btw, the idea behind this, as you said, isn't for normal programming, > it’s for AI, and helping the app think by itself, so that it could create > variables and constants easily, on its own, when it needs all that. >> On Sep 4, 2016, at 9:33 PM, David Sweeris <[email protected]> wrote: >> >> >>> On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution >>> <[email protected]> wrote: >>> >>> Hey! There should be an option to name variables AND constants dynamically. >>> For e.g. in an app from storing recipes, where the user creates a >>> recipe,the recipe should be stored in a constant (as a structure) with a >>> name “\(TitleTextField.text)_Recipe” (e.g. “Lasagna_Recipe”), so that it >>> gets stored easily and therefore fetched even easier. >> >> I'm not sure I understand... Are you suggesting we be allowed to declare a >> variable like this? >> var foo = "bar" >> var \(foo) = 42 //is really named `bar` >> >> If so, how do we then interact with it? Having to write >> \(foo) *= 3 >> doesn't seem any better than >> bar *= 3 >> Plus, string interpolation could get real tricky to read if someone nests >> the naming redirections, so to speak, too deep. >> >> At least for "normal" programming, I don't think I get it... >> >> Outside of that, I wonder if this idea might be part of a conceptual basis >> for some sort of fusion between interpreted code and complied code, or maybe >> part of the fabled macro system. >> >> - Dave Sweeris > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
