Array - Collection - Dictionaries?

[Isaac]

Oh dear! I would rather it be this one, as this is where ideas were much more fully developed - and includes my rare big hearted apology, of course!
Ha ha.

The only slight critique I have of his article is the final bit. Some readers, I already know, those who are predisposed to have an "Ahh - pshaw" attitude towards terminology, will take that as an insinuation that anyone who takes semantics seriously is just an argumentative crazy. Nothing could be farther from the truth. A focus on correct terms, for me anyway, has been almost a currency of success. Sometimes I get it wrong, absolutely. Sometimes I get [anything] wrong. But the strong focus on it is definitely not wrong, in fact I think the same thing in reverse: In my experience, "there are always those few people who get annoyed any time it is suggested they be diligent on terminology". I was wrong in this case, but an almost obsessive determination to put correct terminology on a pedestal is in fact a good thing....IMHO.

I don't think until this thread I had realized, myself, how strong my "terms" preferences were colored by what I think makes a person's tech career strongest, rather than the actual correct term of the platform. Sometimes you don't know yourself until other people hold a mirror! But I admit it.

After all, my tagline signature would be embarrassing if I couldn't be humble when I'd been wrong. That's why I leave it there, as flushed as it makes me sometimes, it keeps me (a little bit) honest.

 

[isladogs]

@Isaac
I had completely forgotten there was an earlier thread where you first raised the fields vs columns issue.
TBH I stayed out of the discussion until you also made the point that all number variables should be Long.

Over the years I've got bogged down in too many arcane discussions which stray far from the original point of the thread.
These days, I try to stay out of such discussions as too often they degenerate into slanging matches
Pleased to see that didn't happen here

Anyway, why not make a response explaining your viewpoint in DP's article? Unfortunately if you give a link to this thread it won't get published

 

[NauticalGent]

Anyway, why not make a response explaining your viewpoint in DP's article? Unfortunately if you give a link to this thread it won't get published

 

[Isaac]

Colin I appreciate your response and the "vote of confidence", so to speak.

I've seen people confidently assert something which is later forcefully corrected by .. others .. , and seen that first person keep digging themselves in deeper or excusing it because saying I was wrong is so hard for some of us (lol, including me) - and it was such a terrible look. I don't want to be that person, but could come perilously close if tempted or provoked by way of additional comments which give rise to any more conversation.

Your idea is a good one, and I considered it, but I've decided to just let everything lie where it lies now. DP's brief 'article' stands as a testimony to me of an argumentative side of myself I'd rather remember to keep under control in the future.

 

[NauticalGent]

DP's brief 'article' stands as a testimony to me of an argumentative side of myself I'd rather remember to keep under control in the future.

If you are saying that DP was signaling you out, I would disagree. I think he was poking everyone who took a side...

 

[The_Doc_Man]

I posted something in another thread that is relevant to this thread. See post #32 of the linked thread to see the whole article.

Why the CRUD approach is needed?

You're talking about DAO now, which isn't what we were discussing, but I'll agree with the cantankerousness part, as that took some serious reaching! :LOL:

www.access-programmers.co.uk

To keep it short here, the international SQL standard from 1999 says that (in the context of "standard SQL") a table has columns and a row has fields.
Therefore, there is some justification in "column" nomenclature, particularly if you are using Access as the FE and any active SQL engine as the BE. However, because the Access object model explicitly calls for "field" in that context, there is considerable justification in "field" nomenclature.

In an earlier part of this thread, the discussion came up regarding why one might use smaller variables in a VBA context. The answer MIGHT well be that you want the run-time system to ABSOLUTELY ASSURE that you don't try to inflict a data abomination on yourself. Strong-type languages like PL/1-G and ALGOL and PASCAL require you to describe your data as well as your procedures. VBA tends to be loose about that, and in that sense, is very forgiving for beginners. It's a blessing AND a curse.

Trust me on this: when your value has to go into a hardware-constrained usage (screen RGB color as a good example), there is ZERO forgiveness. Therefore, strong data typing is a safety feature, like having a belt AND suspenders. In that situation, if you know you are expecting exacting usage, perhaps an explicit shorter data type can be useful.

I've mentioned this before. If you don't absolutely know your project's data requirements, you have either made a mistake or you got lazy during initial planning. In one place I worked, we had to compute tolerances as well as actual measurements. Well, in software, having the right sized (and right typed) variable for the value you are computing is an example of having computed the tolerances on the value in question.