Without reading thread (only reading last post).
That would be a STRUCT.
public struct Cow
{
public decimal weight;
public string color;
public string sex;
}
Public/Private ...welcome to the C based languages.
Thanks John,
If I properly understood I could create an array of struct instances and manipulate all of them within an iteration.
So respectively a (sub)list with items that stand for different properties, in C# thats a customly defined object with a customly defined properties/methods.
Well.. you know LISP aswell so you know from what mindset I'm switching to here.. (<mapcar_in_C#> 'MyMethod <Array/List/Collection>)
The main difference between LISP and C# is about dynamic vs static typing.
Ater I discovered for myself the static typing, started realising the fact -
That one could create a custom list, that can contain any variables aswell other lists..
so it could end up as uneven hierarchy of variables is now mind-blowing for me. i.e.:
'(0 2 "string" (123 nil <object> "I define" (("whatever") "I") "want" <function> (34 PI)))
After John's reply I now imagine that such random hierarchical structure of variables
would be possible to create in C# by defining classes/objects/methods (afterall C# is a OOP language <DUH>)
I brought that question from
Reply #17, because afterall I'm comming from a dynamic typing language (if I blank-started a static type of langugage I probably wouldn't imagine such fancy structures soon)
This also one of the main issue when mixing both laguages (with the execution context).
Trying to work on that one,
At the moment I think a good practice for me would be working on a console application project,
where I add few Class(es) as separate .cs files and test how I'd print out different variables in the main.
Still would accept any other advises regarding on "how to understand the execution context in VS".
The ResultBuffer (or the TypedValue array) provides a way to communicate between LISP and .NET when collections of different types instance are necessary. Each TypedValue embed a Value property (of type Object) and a TypeCode property (of type short) which allows to easily cast the object to its type.
I haven't read the whole thread either but the crux of Lisp<->.net/C/C++ interop is just marshalling data using resbuf's (ResultBuffer in C#) as one parameter rather than many parameters, the rest is just a function call passing the data to the called function at either end. This called function can use this data and if required it then needs to build the result buffer with the results to return the values.
COM is similar but much more involved just to save building resbuf types of structures to marshall data back and forth but that's what's going on under the hood.
If you think of it like that it's easy
Now its more clear what gile did in his demo codes, thank you guys for the resume explanations!
I thought he was asking a different question at the end about lists in Lisp vs C# -ie. how you can "mix data types" in lisp but not C#. I apologize for my drive-by answer (next time it will be to issue a cat call).
Well you thought right, John.. and its not you -
I must apologise for the additional questions, its because one thought of mine led to another, and you guys are so generous answering so I felt lucky!
For short: redirected so much from the topic question that I ended up asking on how to bridge the gap LISP<->.NET
.. or just to get rid off some of the LISP limitations ... (first one was the datagridview) ..next one would be to prompt like this:
Which is far more effective user prompt than my
GetStringList - with DCLDidn't think I would push-off that soon without
gile's help in here!