AutoHotkey Community

[list]
[*][b]Commands with subcommands[/b]:
[*][b]Other Commands[/b]:
[*][b]Errors in math ops[/b]:
[*][b]Errors in math funcs[/b]:
[*][b]Errors in COM[/b]:
[*][b]Errors in RegEx funcs[/b]:
[*][b]Objects[/b]:
[*][b]Classes[/b]:
[*][b]Misc[/b]:
[/list]

• Commands with subcommands: Yes to everything except merging Gui with non-Gui commands. The GUI API should be separate, and preferably it should be redesigned to follow OOP (volunteers?)
• Other Commands: Rename MouseClickDrag to MouseDrag. Remove MouseClick. Expand Click with Speed option.
• Errors in math ops: Treat non-numerics as 0 and optionally provide warning.
• Errors in math funcs: Throw exceptions in all cases.
• Errors in COM: Throw exception on COM error in all cases (except for E_NOINTERFACE in ComObjQuery)
• Errors in RegEx funcs: Throw exception on PCRE failure.
• Objects: Introduce dedicated Array type. Keep meta-functions. Do not remove Integer keys, as that would significantly decrease performance in sparsely populated arrays (i.e. NOT sequential arrays, which would be covered by the Array type) by adding unnecessary string conversions. Yes to all proposed Object methods and properties.
• Classes: Make base a reserved in class methods. Add partial class support: partial class Whatever. Replace default base object with Value, String, Integer, Float and Object classes.
• Misc: Yes to proposed address-of operator change, and to VarSetCapacity() returning 8 for variables containing integers.

• Errors in math ops:
  Should throw an exception. Empty variables contain empty strings, which never should be treated as 0.
• Errors in math funcs:
  Same as above.
• Classes:
  Make base a reserved word in classes. So the following will set the base for Dummy:

  Code: Select all

  Class Dummy {
     ...
     ...
     Class Base {
        ...
        ...
     }
  }
  

• Settings:
  Maybe changing of such settings could be treated as local when used in functions?

lexikos wrote:There are two mutually-exclusive possibilities presented under the Standard Library heading. You can't have everything.

lexikos wrote:What is your view on reserving these names for this purpose? I am against it.

just me wrote:So the following will set the base for Dummy:

just me wrote:Maybe changing of such settings could be treated as local when used in functions?[/list]

fincs wrote:Oh really?

fincs wrote:Portability is a non-issue as the compiler ...

lexikos wrote:

just me wrote:Maybe changing of such settings could be treated as local when used in functions?[/list]

I think the cost would be too high. As a workaround, you can create an object which restores the settings when it is destroyed, then store that object in a local variable.

lexikos wrote:That would add overhead and has no apparent purpose.

Zelio wrote:Why not,

it can be very elegant.

lexikos wrote:That would add overhead and has no apparent purpose.

vasili111 wrote:... Focus on compatibility very often brings unnecessary complexity...

tank wrote:

lexikos wrote:That would add overhead and has no apparent purpose.

I might add its a little programmer centric as well. objects are in general difficult enough for non programmers to grasp lets not do things just for the sake of oop

fincs wrote:Keep meta-functions.

Do not remove Integer keys, as that would significantly decrease performance in sparsely populated arrays

Yes to all proposed Object methods and properties.

lexikos wrote:The question wasn't whether to keep them, but how can they be improved or simplified to make them easier to understand/use?

lexikos wrote:(Anyway, I had no intention to remove integer keys and don't recall suggesting otherwise.)

lexikos wrote:These make the dedicated array type unnecessary, except for performance (in theory! and yet, performance is fine as is), which is completely not my concern for v2. Even that concern can possibly be solved by optimizing objects to automatically choose between methods of storage, as Lua's tables do. That would avoid the loss of flexibility and need for re-training users.

fincs wrote:... and who directly calls meta-functions anyway?

I think that most of the confusion with meta-functions stems from not having a proper way for introducing property handlers in classes ... That way it is not necessary to deal with meta-functions at all in most object-based code.

I suggest adding __GetProp and __SetProp meta-functions that are attempted to be invoked (for string properties) before __Get and __Set proper are tried.

• Defining get foo in class y creates a Property and stores the getter method in y.foo.get.
• x.foo recurses into y, which sees that y.foo is a Property, so invokes it.
• Since this is a "get" invocation, the Property calls y.foo.get.

Having obj[key] behave differently than obj.key is IMO inconsistent,

lexikos wrote:The point is that having the behaviour depend on whether the function uses 'return' or not (as opposed to depending on the actual value) is a foreign concept.

lexikos wrote:With a little more work, get foo and/or set foo(value) could be added without sacrificing compatibility or the ability to get method references

lexikos wrote:Isn't that the whole point? If they behave differently, they are inconsistent by definition. In C#, the two syntaxes are used for completely separate purposes; x[y] is typically used for accessing items in a collection, whereas x.y only accesses properties. Properties generally don't need to be accessed dynamically, so separating the two would conveniently avoid any conflicts such as x[foo] := bar accidentally changing the object's "class" because foo = "base". That wasn't really the point though; the idea (just an idea) was to allow this opt-in functionality (or change the meta-function interface to allow for such things to be added later), for flexibility.