Exactly...and here I was thinking it was a term that I had not yet heard because I do not have a computer science degree. Nice to know it was because MSFT just came up with the name without explaining the reason for their naming it this way.

You and Marco hit it on the head - I like things named as close as possible to what they do. When I name a function or procedure, I often go back and forth between something fairly simple and something more exact but verbose. I usually end up on the verbose side of things (as can be attested by my postings here) but rarely regret them - yes, I often have to look up the procedure name to get it right but there is rarely any confusion as to what it *does* once I have that.

I am afraid that when someone takes over my work a few years from now and they see the number of comments in my code, they will say "holy xxx". Mind you, most of it is "business logic" i.e. how the client wants things done and why, tests etc. My main client has about a dozen partners and I often have to review with them who made what decision and why and why the alternatives were not done etc etc. Rather than a file drawer full of paper that will eventually be lost, the person who take over my work will be able to read why things were done as they were and they will not have to start from scratch and rely upon people's poor or non-existant memories as to why things were done as they were (sorry, this is a bunny trail from the original thread...).

>
>I don't like using terms whose authors built them with disregard to what is the meaning of word they used. Serialize is, indeed, something that doesn't sound what it's doing; I understood the concept long before I accepted that this is the word to use for it. Because either json or xml or whatever you use are not turning the object's structure into a flat series of items - they are structured, there's containership. Flattening may be a better word, or perhaps betexting.

---> or "convert" - converting from an object to a string-based structure....but that is probably too vague (although it is still better than "serialize".

(and from Marco...)

> Naming things is one of the most important things

Totally agree!


.. I also had that question when I started
developing nfJson ( a json Parser / Serializer you can find on github.com/vfpx ).

Since "serialize" is a procedure applied to a vfp object, and Parse is applied to a Json string,
there was no clear way to name the functions to do it; JsonParse() ? ok.. but a serializer
can output xml, json, yaml etc.. and jsonSerialize() was not a choice, because we
don't serialize Json, we serialize "objects as json" ... so in the end I felt comfortable just
using the terms jsonRead() and JsonCreate()..