nnnik wrote:You are wrong on several aspects:
A: It is not a lot more used, there are just a lot more questions asked about it on Stack Overflow ( I'm 100% certain that COM Objects are used more often )
Well if you have better and more accurate "usage statistics" then be my guest to post them... The StackOverflow questions give a "hint" towards what the real numbers are, as I said. A better way, rather, would be to take a commercial application and search for uses of StrJoin and usage of ComObjCreate() (or equivalent). I am 100% sure that COM Objects aren't used as often as StrJoin equivalents in commercial software (and thus generally in programming). I can imagine they are used for setting up APIs/Automation Opportunities and increasing interoperability with other software, but, as I understand it, application's programmer's generally write (or are instructed to write) self-contained code (in the end, most users use the software IN the software itself) and don't rely on external applications (where they can benefit from COM).
We don't care about general programming. This is AutoHotkey meant for automating other applications and thats what COM-Objects are made for.
nnnik wrote:B: join string join array etc.. is a general term and may refer to almost anything including COM Objects aside from your function ( Where as COM may only refer to COM )
Where COM Objects and StrJoin are included together both should appear in the search results, one would assume. But again, they're very rough figures, as I previously said.
You didn't understand what I meant here and I'm at a loss at how to explain it.
nnnik wrote:C: COM Objects are not functions it is an object. The functions in COM.ahk did not fulfill what COM really asked for and were a poor implementation ( That's why it was redone as soon as objects were added )
I know what a COM Object is... And I know it isn't a function, and never said it was? I was claiming the functions to create such a COM object were vastly more complicated than the function used to join an array.
I just wanted to make clear why COM Objects where built in to AutoHotkey when AutoHotkey_L came out
nnnik wrote:D: It is not exactly simple. StrSplit causes a loss of information. How that information should be reconstructed differs on a case to case basis and is therefore up to the programmer to implement.
StrSplit causes a loss of information. Yes. That loss of information is chosen by the programmer.
Similarly, StrJoin causes a gain of information. That gain of information is chosen by the programmer.
Hence the delimiter argument. What's your point?[/quote]Whether the programmer is able to choose how the information should be gained again depends on how exactly the function looks.
Imagine using StrSplit to parse an HTML document and now you want to redo that by using StrJoin.
StrSplit(str, ["<","<\>"], "`n" )
How would any simple StrJoin function be able to regain that information? It it has to be a lot more complex to let the user describe how that information should be regained.
And here we are at the core of the problem. Gain of information happens when you merge already existing information with some kind of context.
For simple StrSplits e.g. ( StrSplit( Str ) || StrSplit( Str, "SplitChar" ) ) the context would be that the StrJoin function should join without adding anything or with adding "SplitChar" between each border.
However as soon as there are more than one SplitChar the StrJoin function will have troubles recreating that.
Maybe you could extend the function with something similar to a Format String or maybe have it process something like an analyzer function.
However all that just won't cover all cases of StrSplit. There simply is no single simple counterpart for StrSplit.