AutoHotkey Community

[bmcclure]

I like that idea. I preferred the original function names, but now I see the logic in changing them anyhow. Thanks for the reply!
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Well, in most cases, you will probably be calling the functions directly via their class name function, not the interface ones, right? The main thing I'm hoping from interfaces is to create a "standard" (like LogI, IniFileI, etc.); then, users would implement these classes making their own additions. The interfaces would be updated with additional functions as the need for such functions arise.

Since the class would implement the respective interface, you know that the core functionality remains consistent between the classes. Therefore, it would be easy to test out the different implementations and see which one does what you want.

The fact that interfaces would have the "I' says immediately that they are interfaces. I didn't use an "I" for the List interface, because I was using the Java List interface as a basis and wanted to preserve the naming. Also, with Array and Vector already devolped, there is no need for a "list" class.
_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

[bmcclure]

So how far do you go building functionality into the interface, as opposed to leaving the functionality for the calling class to implement?

Most of my DOM interfaces, probably because they didn't start off as interfaces, handle almost all of the processing internally, and really only require the calling class to construct the actual objects and add any non-official DOM functions. Should I be moving the functions out to the calling class and just referencing them from the interface, as is seen in Coin (save for its single static function)? Or is it acceptable to keep a large number of statics in an interface?
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

[bmcclure]

Thanks, that clears it up. I just need to further separate my logic from the interface and implement that in the classes.

The reason I'm using interfaces at all for the DOM is to follow the DOM specification... I want to create interfaces, and a set of default implementing classes, but allow anyone to create their own implementing classes however they see fit, as well.

Some of the interfaces truly need to be interfaces to function properly, I believe. Most of them directly correspond to real objects, however, and are just made into interfaces to separate the definition of the functions from the actual implementation of them.

I'm seeing the use in moving almost all of my logic outside of the interface and leaving it a shell, as it should be. Thanks again for helping clear that up.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[bmcclure]

What about the possibility of supporting just the function name (with no Class name and underscore) for the FunctionName parameter of Class_call?

That would make it more useful to be able to call other classes without knowing the class name.

For instance, my DOM class needs to call a certain function within the class of an object it is passed in one of its methods.

Rather than calling Class_getClassName and then manually creating the function string, I'd like to be able to just do something like:

[animeaime]

[bmcclure]

I've been debating whether or not I think that the order of the parameters of Class_call should be changed, actually, and now that you bring it up, it seems like a good idea. It follows the normal OOP order of object.function(parameters).

I'm using Class_call in about 25 interfaces right now, but it would be a simple search and replace operation in each of them.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Ok. sorry about that. I modified Class_call and Class_Scall to have ClassObject then FunctionName as the inputted parameters. Also, I added Class_invoke and Class_Sinvoke. The error messages match the ones from Class_call; "-3" is the error level (using the return from Class_callError) if the passed object isn't a class object (e.g. 0 or the empty string was passed).

For all four functions, you can call Class_callError to see if the call resulted in an error, and the error (if any, or 0 otherwise) will be returned. I've update the page on Interfaces to reflect the changed parameter order. I'll add a page for Class_invoke / Class_Sinvoke shortly.

The List and Coin interface were updated to use the new syntax. I used the below RegEx to swap the two parameters. This will swap the first two parameters for all Class_call and Class_Scall functions. It assumes that "A_ThisFunc" is the first parameter, which it should be if you followed the format used in the List and Coin interface.

[bmcclure]

Modified the replacement value for backslashes instead of dollar signs, and the regex worked perfectly in EmEditor on all of my DOM interfaces at once Thanks for that.

And thanks also for invoke. I haven't been able to test yet, but I'm using it as required already in the DOM.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[bmcclure]

Is it possible for invoke to accept the function name as a string instead of a ByRef?

To get a parameter of an object from an external class, I'd like to be able to pass Class_invoke(Object, "getSomeParam"), for instance. Right now it throws an error because it's looking for a variable reference instead.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

[bmcclure]

Sorry, I noticed that too; I must have misread the error message from AHK.

Yes, I was referring to the parameters. More often than not I'll be passing variables to Class_invoke for its parameters, but it would be nice not to have to.

You bring up a good point, though--it would also be expected to work when passing a byref, so changing it might not be the best option either.

I can't think of any graceful way to get around it; I could just assign the values to variables and use them with Class_invoke how it is now, or perhaps a second function could be created without byrefs, maybe Class_sinvoke (for string invoke) or something?

Now that I understand its purpose, it does seem like a good idea to leave the invoke function using ByRefs as you've designed it to do.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Well Class_Sinvoke is taken - (Static) invoke. However, as a programmer, I would call the version you are talking about ByValue, whereas the current method is ByRef. So, maybe Class_Vinvoke (for byValue) and Class_SVinvoke for the static version would be good names. However, might I make a suggestion. You can store the values in a temporary variable and pass it.

Example

[bmcclure]

I think you're right, turning them into variables for the function call will probably be the easiest way to go, and will avoid the need to create additional functionality for Class.

It would be great if Class could automagically determine if a parameter should be a byref and pass it accordingly, but I don't think it's possible currently.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music