C# isn't really my cup of tea, but from what I know about LINQ; I'd say that's code, not data. You couldn't put that expression in a database, read it back and interpret it without some serious hoop jumping.
The lines get blurry in Lisp, since the code is explicitly encoded as a data structure (tree).
LINQ expression trees can be serialized with a custom serializer, but it's a mistake to do so for a different reason: deserializers which materialize code or substitutes for code are major vulnerability vectors. Anyone who has had to upgrade Jackson or remove naive pickling will be familiar.
Arguably, as long as you don’t allow specifying arbitrary types in the serialized format, it should be safe as you can’t otherwise construct gadgets to produce unexpected side effects.
I'll concede your point about saving LINQ in a database.
But you know what I can do, in a day...
Take a rule, written as a function in C#,
compile it to an assembly,
save it in a database with a name and checksum,
and then dynamically load it later when I want to execute it.
The lines get blurry in Lisp, since the code is explicitly encoded as a data structure (tree).
reply