Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Choose naming and syntax for built-in Extract/InsertInteger


  • Please log in to reply
100 replies to this topic

Poll: Pass "VarOrAddress, Offset" (20% faster and possibly less error-prone) vs. "&Var + Offset" (fewer parameters and more pure)? (13 member(s) have cast votes)

Pass "VarOrAddress, Offset" (20% faster and possibly less error-prone) vs. "&Var + Offset" (fewer parameters and more pure)?

  1. I strongly prefer passing the single parameter: &Var + Offset (0 votes [0.00%])

    Percentage of vote: 0.00%

  2. I slightly prefer passing the single parameter: &Var + Offset (3 votes [23.08%])

    Percentage of vote: 23.08%

  3. I strongly prefer passing two parameters: VarOrAddress, Offset (4 votes [30.77%])

    Percentage of vote: 30.77%

  4. I slightly prefer passing two parameters: VarOrAddress, Offset (3 votes [23.08%])

    Percentage of vote: 23.08%

  5. No preference. (3 votes [23.08%])

    Percentage of vote: 23.08%

Vote Guests cannot vote
PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

These functions fully support structs. Propose a more user friendly syntax, if you don't like the current one.

I already made several proposals for this, and I am not alone, some changing syntax a lot, others trying to fit in the existing syntax.

corrupt, I don't agree, even if these functions will be used primarily for structure handling, their scope is broader than that, as they allow unstructured random access to a memory area (eg. finding Ascii content of a binary file, etc.).

I note that nobody proposed Peek and Poke names, which are probably familiar only to those having programmed in Basic on 8bit computers... :-D
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

Even if these functions will be used primarily for structure handling, their scope is broader than that, as they allow unstructured random access to a memory area (eg. finding Ascii content of a binary file, etc.).

Indeed. There is no question about usability of this.
Posted Image

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

Even if these functions will be used primarily for structure handling, their scope is broader than that, as they allow unstructured random access to a memory area (eg. finding Ascii content of a binary file, etc.).

Indeed. There is no question about usability of this.

...but the names are not descriptive enough for new-intermediate users - the target audience. In fact, they are cryptic. Personally, I wouldn't think to look for or recognize by looking through a help index any of the cryptic names mentioned so far (including InsertInteger/ExtractInteger). Although these functions can be used for other purposes, that's not the main reason they were put together and not what they would primarily be used for. I think that the names should reflect their primary usage.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Does anyone else want the names "StructGet" and "StructSet" to be considered? If so I can reset the poll again. I don't think this will delay anything because it might be a week or two before I get the next set of features done, which might be called 1.0.47.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

Does anyone else want the names "StructGet" and "StructSet" to be considered?

I'm afraid corrupt actually looks from the viewpoint of a programmer.
It's highly likely for average users to know what Num means, but I don't think not many would with Struct.
What struct? There is no struct here, they might say.

As a matter of fact, they are good names, so should be reserved for the genuine struct until it's implemented, IMHO.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

I'm afraid corrupt actually looks from the viewpoint of a programmer.
It's highly likely for average users to know what Num means, but I don't think not many would with Struct.
What struct? There is no struct here, they might say.

You might be right but how many users would think of Numput or something similar for putting a pointer to a string into a variable. Users are much more likely to try and use DllCall then see a reference on a site somewhere to the need to use a structure then search the help documentation for how to create a struct. Not how to put a num into something.

As a matter of fact, they are good names, so should be reserved for the genuine struct until it's implemented, IMHO.

I see your point but I disagree since I think the next step should be to allow users to assign values to/from struct without having to use a function at all so I don't think that should be a consideration. Rect.Left := 10 or Leftvalue := Rect.Left

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

You might be right but how many users would think of Numput or something similar for putting a pointer to a string into a variable. Users are much more likely to try and use DllCall then see a reference on a site somewhere to the need to use a structure then search the help documentation for how to create a struct. Not how to put a num into something.

IMHO, if he doesn't know what setting a number into a buffer is, he's less likely to be able to manage DllCall().
BTW, if you have specifically DllCall() in mind for the usage of the struct, DllStructGet/Set might be better names.

I see your point but I disagree since I think the next step should be to allow users to assign values to/from struct without having to use a function at all so I don't think that should be a consideration. Rect.Left := 10 or Leftvalue := Rect.Left

I think both forms should be supported.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

the names are not descriptive enough for new-intermediate users - the target audience.

No, the target audience is the people knowing how to properly use DllCall, not the beginners wondering why Foo(%x%) doesn't work...
Somehow, a cryptic name is better, if they put off beginners from using these functions. They are perfect to show a bullet in the foot, like writing beyond the variable space (or in a neighboring variable!).

I think the next step should be to allow users to assign values to/from struct without having to use a function at all so I don't think that should be a consideration.

Well, that's speculation, since we don't know how structure handling will be implemented...
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

  • Guests
  • Last active:
  • Joined: --

No, the target audience is the people knowing how to properly use DllCall, not the beginners wondering why Foo(%x%) doesn't work...

That's not AutoHotkey's target audience and if something is going to be built in it should cater to the target audience.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
I meant target audience of these functions! Not of AutoHotkey in the broader sense.
If you target only script kiddies, let's remove DllCall and the future callback support...
Actually, even script kiddies can take advantages of these features, if wrapped correctly to hide them (like my binary reading/writing, clipboard or GDI+ wrappers).
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

That's not AutoHotkey's target audience and if something is going to be built in it should cater to the target audience.

Ofc it is. This is low level part of AHK and will be used by more advanced users directly
Posted Image

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
I may be wrong but it seems to me that the only people that will know what NumGet / NumSet are (or the other names currently suggested in the poll so far) , are the ones reading this topic. Honestly, if you had never used AutoHotkey before, and I'm not talking about beginners to programming/scripting or people who don't program at all, how many people would honestly even remotely think of looking for NumGet / NumSet in the help documentation for use in creating/modifying structures? I'm 99% sure that the answer would be zero unless the help documentation also listed structures and pointed to the relevant page with an explanation. If that's the case though then that should tell you that the name doesn't sufficiently reflect it's intended and most common use. If I didn't know much about AutoHotkey and, being a programmer, wanted to use a struct in a DllCall function, I wouldn't ever dream of looking for NumGet / NumSet in the help documentation. I'm not sure I understand the logic behind the name suggestions that have been made so far. Get a num from what?? Set a num?? math? file operation? random number? bingo? I think it only seems to make sense to some peope here because they already know the intended usage and are familiar with the current InsertInteger/ExtractInteger functions. I'm almost positive that nobody else will...

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

I think the next step should be to allow users to assign values to/from struct without having to use a function at all so I don't think that should be a consideration.

Well, that's speculation, since we don't know how structure handling will be implemented...

Adding get/set functions for struct use as built-in later doesn't seem logical since that's the current usage.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

IMHO, if he doesn't know what setting a number into a buffer is, he's less likely to be able to manage DllCall().

NumGet / NumSet does not suggest setting a number into a buffer. The word buffer is not referenced and Num could be anything.

BTW, if you have specifically DllCall() in mind for the usage of the struct, DllStructGet/Set might be better names.

Maybe, and a good suggestion, but it wouldn't be as easy to search for in the help file other than the fact it would be listed alphabetically near DllCall and is a bit more to type.

I see your point but I disagree since I think the next step should be to allow users to assign values to/from struct without having to use a function at all so I don't think that should be a consideration. Rect.Left := 10 or Leftvalue := Rect.Left

I think both forms should be supported.

They would be if Rect.Left support, etc.. is added later since the not so user friendly method is currently being added. That would end up supporting both methods.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

This is low level part of AHK and will be used by more advanced users directly

Advanced users are considered bottom feeders here... remember? :lol: :p