AutoHotkey Community

[animeaime]

[animeaime]

Ok, there is a TON of new stuff - there is a high probability I'm leaving something out. If that happens, I'll post the other updates when I find a feature I forgot to share. You can download the updated zip.

I want to state that I still haven't fixed the shallow clone - still wrapping my mind around it - been focusing on other areas. Also, the Dictionary classes that are added are in a "beta" state. They work, have no memory leaks, etc; however, I may change the internals. This won't affect your code, so don't worry about it, but this is why the features for the Dictionary classes aren't up to par with Vector and Array - I need to decide what to do. I'm thinking about adding hashing, because lookups take WAY too long. On my computer it takes around 1 second to add 2500 "dictionary entries" (I can add 5000 Vector entries in the same time). The internals of the Dictionary classes are set-up to allow changing it to a HashMap. Don't worry, all additions or changes will be backward-compatable. I wanted to get it out, so that it can be incorporated into code. When I figure out the small details, I'll upload the updated version.


Functionality that affects Array is updated in Vector as well (and visa-versa)

Updates:
1) Added "Type options". Specify NoEquals / NoClone to skip a Class' value during an equals / clone operation. For example, instead "uint" specify "NoEquals& uint" to skip the value during the equals operation, specify "NoClone& uint" to skip the value during clone, and specify "NoClone& NoEquals& uint" to skip the value during both. The space between is optional (used for clarity).

2) Added Dictionary & SDictionary Container classes. These are a mapping / dictionary class that associates a key to a value. See the included Dictionary_test.ahk and SDictionary_test.ahk for usage. For both classes, only Strings are accepted as keys (value is an class object). The key can only be used once. Use Dictionary_put (mimics Vector_set) or Dictionary_replace to set a new value to the key. If the key doesn't exist, it will be created. There is no "add" method, use put or replace instead. The difference between the classes is that Dictionary uses case-insensitive keys while SDictionary (case-Sensitive Dictionary) uses case-sensitive keys. Otherwise, they function identically. Both are based on Vector, so their capacity grows as needed.

3) Overloaded Vector_indexOf type functions to allow both these formats:

[bmcclure]

This sounds awesome! I'm in portland for a couple days looking at houses, so I apologize for my lack of response to this so far.

Dictionaries will be extremely handy to me in the classes I'm working on right now. Currently it will store the parameters used when an installer was called for my Installer class (mapping parameters to values), but I can already see other uses for it.

Although it would be nice if it were faster, I don't think half as fast as Vector is too bad, seeing as Vector is so fast anyhow, and a dictionary needs to map two objects for each definition.

I might have missed this in your explanation, but for which cases would you use replace instead of put? Does replace only work if the key already exists?
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

No problem, enjoy yourself.

[animeaime]

I'm modifing the Dictionary class to use a HashMap instead of the inefficient LinearMap it uses now (it will not require changes on your end). This will allow each put / get to work in constant time, O(1), instead of linear, O(n). This will drastically spead up the class.

I've been debating whether to force "equal" number keys to be treated as the same key (this is the current behavior). I've decided that this is best for simplicity of use. For example, these keys are all identical (as seen by the dictionary class): "2", "02", "0x2", "0x02", " 2 " (leading or trailing space / tabs are allowed), "2.0" (even though is a float, it equals the integer 2). This means that regardless which format the number is in, the key is the same. Note, this only effects numberic keys. For example, "0xz" and "z" are not the same, since "0xz" is not a hex value. Now, "0xa" and "10" ARE the same, because both equal 10.
_________________
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.

[animeaime]

Evidently no one has been using Vectors or the Dictionary class. I found syntax error in the ReAlloc method - I typed something I shouldn't. I fixed it and updated the zip.

There are no updates in this release, just that "bug" / typo fix. I just finished implementing Dictionary as a hash map and was testing the old version and found that bug. It's sad, and I was worried this might be the case, the old linear search method is quicker than hashing - this shouldn't be the case (logically speaking that is). My quess is the fact that, like CDLL, because a hashTable / hashMap creates a new object for each added node, this is sadly always going to be the case. I'm going to check, tomorrow, and see if I can't find a way around this. If not, then we'll still have a Dictionary class, but it will use a linear search (much like Vector would) to search for it's value. In theory at least, a hashMap which provides contstant time lookup and add should perform better than the current Dictionary class. Currently, it has linear lookup, O(n), and constant add, O(1). However, theory goes out the door because for some reason object creation isn't cheap.

I'm trying to optimize the library, but I haven't yet isolated why object creation is so expensive. I mean, it's a memory allocation and a bunch of puts (maybe that's the problem...). I might find out that's the limit. Maybe AHK DllCalls can't go faster, maybe NumPut - not sure. I'm not one to give up and say "hey, it's the language, not me". I mean, maybe this is the case, but it's too early to throw in the towel.

I'm going to work on it a little tomorrow, but more than likely, the Dictionary class will remain how it is, and I'll focus my attention more on optimizing the library - which is time well spent - if I can optimize it some.

Well, that's the progress. I'm not going to spend more than a day on this though. My quess is that I've hit the glass ceiling of semi-interpreted scripts. However, it's a pretty high ceiling in my opinion. Just want to say thanks to Chris for adding tools that allowed this library to spawn. I mean, being able to programically create OOP in a non-OOP language - for this, I owe the credit to Chris for all the wonderful toys he gave me to play with. Without them, this project wouldn't have been possible.

Edit:
I just realized. The numbers I posted before for the Dictionary's speed had the typo in them - I was wondering why they were so fast. I'm now getting values like I remember (when first testing).

Dictionary speed tests:
On my computer, it's taking 1 second for 500 insertions and 4 seconds for 1000. As stated above, insertions are linear. So, inserting 1 item takes n loops (to see if the item already exists); thus, inserting n items takes n^2 loops. So, as you double the number of items, you quadruple the time required to add them all.

On this note, the new dictionary is better. Yeah! I was very concerned. I was trying to figure out how something with linear insertions was beating something with constant. Good old math, never fails. My code, on the other hand, yeah, it fails time-to-time.

I'll post the new Dictionary Class after I clean it up some.

In the new class, I'm getting about 1 second for 500 insertions and only 2 seconds for 1000. Because insertions are now constant, O(1), it takes about 1 (excluding some collisions) search to find where to insert. So, it takes n to insert n items. This means, double the number of items, and double the time to insert them all. Note, constant time means the time to add a single item is independent of how many there already are. In otherwords, if you have 5000 items, it takes the same time to add a new item than if you had only 100.

Likewise, searches are constant time operations (and very quick). Since a search doesn't need to create an object, they get much better times. It takes about 1/4 of a second to search for each of the 500 items, and 1/2 second to search 1000. So, it might take some time to add items, but to search, it won't. Likewise, because they are both constant time operations, the speed isn't based on the number of items.

Hopefully I can figure out someway to optimize the class library. However, I think those are pretty good times - especially searching.
_________________
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]

That sounds very promising!

And I've been using Vector in most of my classes already FYI, not sure why I haven't noticed the bug--was it introduced in the last several days when I may not have updated?

I'll start using Dictionaries today
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Yeah, the bug was a typo in the Class_ReAlloc function. It prevented Vector (and Dictionary) from resizing. So, if you tried to add more than the initial capacity (default 10) to a Vector, it wouldn't resize, and thus, the new items wouldn't be added.

[animeaime]

Ok, I recently found out about the COM library and got an inspiration from it - allowing "dot syntax" for the Class library.

However, this requires some standardization, and some changes. This will be added in using the class option "3" for (V3 design). This will allow backward compatability as well as ease into this new design (for "legacy" classes). Also, this functionality will be added in slowly, as my attention is on my bookmark manager now, and hastefully adding this feature could lead to problems later on. Right now, the idea is just that, an idea. I'm not sure how (or to what extent) my idea is, but it will be a nice addition.

The goal:

1a) New will remain as is. This allows the class file to be included via use of the library folders.

1b) Destroy will be redone. Hopefully I can use RegisterCallback to remove the need for dynamic function calls (for both destroy methods and others); this is presuming that this method is quicker than a dynamic call. I'm going to try different methods and use the most efficient one.

2) getters and setters:

Getter:

[bmcclure]

It may take some getting used to, but I'm definitely open to the idea.

I never much cared for the COM library's method of setting values using a parameter of "key=" and another parameter containing the value, but I think I can see why it's done that way, and why it could potentially be beneficial for the Class library.

The issue I can see is that it makes "call" calls ambiguous, since you can use it for so many different things, it isn't clear what it really does until you understand the parameter syntax.

My preference would be on creating separate functions, such as a generic "get" function to get a value, "set" function to set a value (eliminating the need for the '=' in the parameters and other things that may not be obvious to users), and a "call" function for actually calling class methods. Though maybe there is an advantage I'm not seeing to keeping the entire functionality within a single function?

I guess I'm more trying to understand the reasoning behind it than trying to suggest an alternate method, since it's likely there are pieces of the puzzle I'm missing currently.

Will built-in and user-defined values still be based off of a byte/word index as before, or is there a different way to access them now (since it appears you've got values stored by name (".value1")?
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Well, you bring up a good point - is it worth it?

1) the code changes in the Class library - and the overhead in adding the feature (i.e. time on my part)

2) The overhead in you (and any "shadow people" using the library - i.e. people in the shadows) changing your classes to make use of the new form

3) The user using the form. Will it be more intuitive for them, or more of a headache?


If there are reservations on the idea, I'll put it away. I was acting more as a programmer (and out of a rare moment of spontaneity), and maybe I should be thinking more of practical use. Maybe it's not practical... good point. So, should I throw it out; it could always be added later if the need arises - less work for me .
_________________
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]

I kind of like the idea, but am somewhat hazy on its exact usage and how it differs from what is currently possible.

I can see that it makes the function call itself more object oriented, so it looks more like Object.method(parameters) than Class_method(Object, parameters).

Speaking hypothetically if you decide on these features: Is it only the calling of the function that is different, but the methods themselves are the same? Is the object still provided as the first parameter of a method, even though when calling it with Class_call it's provided directly?

For example, when using Class_call(Object, ".GetArea()"), does getArea correspond to a standard Class_getArea(Object, ...) function like it would in the current Class V2?

I'm not sure if I'm understanding the full scope of this, but I do understand how its used in the COM library (since I used that for my initial XML classes using your library ), so I'm thinking it's quite similar in concept at least.

--

A couple related questions. If you use () to indicate you're calling a method (as seen in your getArea() line), is the = sign really needed when setting a value? The only thing I can see it being useful for is setting a blank value, to differentiate it from getting the current value; is that the reason? Apart from that, it seems the presence of a third parameter would indicate a set operation, negating the need for the = sign.

Likewise, is the first . (period) before the key name or method required? It seems it's always there, and if that is the case, does it need to be there at all? I know it's generally used to separate the object from the method you're calling, but since they're already separated in different parameters, it seems like it might be extra.
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Ok. Scratch my idea - bad idea. After putting some thought into it (probably should of done that earlier ), I realize that this really won't do much of anything. It probably won't offer a more optimized call (might even be worse, depending). It's not intuitive, and worse it's completely different than the current method.

Sorry for the waste of time...

Next "good idea" I have, I'll think it over first and make sure it's actually a good idea. Sorry to get your hopes up.
_________________
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]

No problem, I think it's an interesting idea none-the-less, but I'll support either way you decide to go. If it adds unneeded additional overhead, then I'm also leaning toward preferring to keep things the way they are.

And I have no problems with you bouncing potential new ideas around first, even if they turn out to not be keepers. It helps get the creative juices flowing and could very well spark additional ideas for features from my end too

--
UPDATE
--

I do like the == and comparison features you've proposed still. Do you plan on implementing something similar in the current Class design, or did that go out the window as well?
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[animeaime]

Thanks for that.
_________________
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.