AutoHotkey Community

Oooooh I just had an idea. Never mind what I just said lol.

If splitting by characters, then pass an array. (like Franke said)

BUT if the parameter is a number instead then split the string with number-characters per index.

_________________
Scripts - License

I was thinking that "delim" and ["delim"] would be equivalent. If you want to use multiple delimiters you can put them in an array. Otherwise just use the one and only delimiter as a literal string / variable containing a string.

It's the most consistent way I can think of. That is assuming multi-character delimiters are going to be allowed at all.

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

StrSplit(String, [SingleDelimiterString]) is just as flexible. It's just a matter of which would be more commonly used: a list of delimiting characters or a single delimiting string.
That was my intention, as implied by my previous post.
This is not of particular concern for the v2 alpha.
I thought of that too, which is why I didn't add that little bit of extra code to convert numeric parameters to strings. But would it really be useful enough?

Another issue is the OmitList parameter: for performance and convenience, it might be best to leave it as is, but it might seem inconsistent.

I often limit output to less than 80 characters. A StrSplit of every 79 characters and then joining them back together with `n between each line would do the trick. Join can be done very easily.


I can't think of any cases why I'd want to omit strings of characters.

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

Thanks for the example. That's very practical.
Even so, it makes sense to provide StrJoin() as a built-in function. Since it can be easily added later without breaking anything, it might wait until after the first stable release.
My point was that one parameter accepting an array and the other parameter accepting a list of characters as a string would be inconsistent. Requiring OmitList to be an array like [A_Space, A_Tab] would be more consistent but less efficient. (I'll probably just go with the easiest approach: leave OmitList exactly the way it is.)

Here's a small wordwrap function:

Deja-vu or is it just me?

Can we please skip all the "here's a function that does that" posts already? If someone mentions an example, they probably already have a custom function to do it.

Sometimes it's nice when the language you're using does some of the more simple and obvious things for you (faster I might add) without having to code it up and test it yourself, every time.


Lexikos: I would leave omitchars as is, I can't think of an example where I would want to omit strings, not just characters.
And I like the length-split idea.

_________________
Scripts - License

Sorry.. I don't do it again!

Agreed. I'll do my best to remember.

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

I just noticed new Class returns a new object even if __New is defined but couldn't be called because required parameters were omitted. Should it be changed so that new fails in that case?

Yes it should be changed. If you have some code in your __New function that's critical to class function (regardless of personal preferences) it should always run.

I get confused with class and prototype syntaxes existing at the same time. Is it possible to determine that new CN() is defined with a minimum of one argument, and thus should give an error? If I had to guess I'd (sadly) say it isn't.

The other side of this would be creating descendant objects dynamically. You did say "even if _New is defined." Well what if it isn't? Would the rules be different to allow the following? Or the same for the sake of consistency?

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

I've said this before: one is syntax, and the other is functionality. Class syntax "can be used to construct a base object" or in other words, a class is a prototype. If the apparent duality bothers you, just choose one way and stick with it.
Yes.

That is a different case to the specific one described in my previous post, and therefore would not be affected by the proposed change.

Your example is equivalent to this:
... except that static initializers are always evaluated before the auto-execute section, and oFirst.__Class contains the string "oFirst". Would you want new oFirst() to fail in that case, since __New is not defined? (You don't need to answer that.)

v2.0-a017-5157e3d:

• Merged v1.1.02.03.

v2.0-a018-38235ab:

• Merged v1.1.03.00.

v2.0-a019-b56df88:

• Merged v1.1.04 (WIP).

I have more planned for v1.1.04, so it's not released yet. See the commit history for a full list of changes. The highlight of this release is try/catch/throw, coded mostly by fincs and reviewed by myself. It affects a large number of commands, so watch out for bugs.