[Idea]Why not get dynamically named variables?

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.

Have you thought about using a dictionary? You can fetch a recipe by looking up a key:

let foods: [String: Foods] = [:] // fill it up appropriately with your own data
let recipe = foods[TitleTextField.text].recipe

Saagar Jha

···

On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution <swift-evolution@swift.org> 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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

···

On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution <swift-evolution@swift.org> 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.

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 <fayez.hellani@icloud.com> 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 <davesweeris@mac.com> wrote:

On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution <swift-evolution@swift.org> 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

Really? How should the fetch happen?
Imho you'll come to Saagars conclusion when you rethink the problem…

Tino

···

Am 04.09.2016 um 19:28 schrieb Fayez Hellani via swift-evolution <swift-evolution@swift.org>:

therefore fetched even easier