AutoHotkey Community

Hmm, not a bad idea I'll look into that. I think it can be done, to allow caching of String, Ints, etc - the legacy wrappers. The one Cache object would cache one type, but the same Cache Class, using different objects, could cache different types. Then, of course, different objects could be used to cache different "sets" of the same type.


Nope, not missing anything.


Yep. That's it. It's the only difference.


It IS a legacy class. There is no difference how it acts, or how you create it. The only difference is when you retrieve that class when stored in anther class (like Vector). If you get the value as an "obj", like Vector_get, it will unwrap. If you get the value as a "uint", like Vector_getAddress, it will return the address (even for the wrappers). There is no difference in the design of the wrapper class.


The difference lies in getter methods which retrieve those objects.

For Array and Vector, use getAddress to return the ClassObject, or use get to unwrap the value (which returns the address for non-wrappers). So, anytime you need the object, use getAddress, and use get to unwrap the value. This ensures that even if a class, at a later time, is converted to a wrapper, the old code will still work. Or, should Vector_get (and Array_get) only unwrap the basic wrappers, and add another function to unwrap all wrappers?

In your own class, when writing a getter:
1) to return a class object (as an address), don't specify a type (uses default "uint")

2) specify "obj" as the type in a getter to unwrap wrappers (and return the address for non-wrappers)


For example, if Rectangle was a wrapper class. And you had a Box class that had 6 rectangles - one for each side.

_________________
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.

You probably didn't see my question, didn't edit it in time.

it might be something like this?

Put this line and execute it - no other needed


However, this only works if you don't use NoEnv - which is recommended to be used for new scripts.

_________________
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.

Ok, I get it now. You can still access it like a regular object if you get it as a UInt instead of explicitely defining it as an "obj" (like I would have done for a standard node class previously).

Cool.

And aside from concatenating a default string as in the example, I'm assuming you could do something cool like return the 1st (or nth) object from an internal vector, which, if it's a wrapper object, would also be recursively unwrapped? Or, maybe, always returning the last-added item from a vector. Don't know how that could be useful yet, but it sounds interesting

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Yeah, some sort of weird behavior due to the fact that the object was already destroyed, it must have somehow turned that into a raw call to the path variable. Even though none of my functions are global

I normally use NoEnv, but haven't been in my test scripts. Maybe this is a good case to start doing so

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

It's your use of <path> in the set path, I think.


Huh? My mind can't figure the context for this. I'm sure it makes sense to everyone else, but I'm lost.

_________________
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.

Sorry, my mind wanders when I get ideas sometimes. It's probably gibberish to anyone but me

I was just trying to think of the various possibilities of using a wrapper, such as returning a particular value (such as the first or last value) from an array or vector. And if you had a wrapped item stored in that position in the array, it would be unwrapped as well.

So, for instance, I could have an array of ID strings, or of anything really, and have the class always return the last-added ID. Or an array of custom wrapper objects, which is what I means about recursion (since they would in turn be unwrapped)

I don't know how it would be useful yet--just basically thinking aloud, heh.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

The class would have to keep track of the last-added ID, since Vector doesn't, but yeah.

I'm still not sure how it's recursive. If you used Vector_get, and the object at that index was a wrapper, it would be unwrapped and the class' getValue function called and its return value returned? How would this be recursive?

_________________
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.

Unless I'm misunderstanding the functionality:

1. The wrapper class unwraps the object and returns its value. This is the first level.

2. The getValue function could return an object from a vector instead of a standard string. If a wrapper class is stored in the vector, it should be unwrapped. That would be the second level.

3. The object that the vector unwraps at the second level could have a similar getValue function which returns a similar object from a vector, which should unwrap it automatically if it's a wrapper. That would be the third level.

4. The same type of object could be returned from that vector, which would have a getValue function of its own calling an index from an internal vector, thus unwrapping the object from the vector; the fourth level.

5. And so on in this fashion until you got as deep as the object takes you (for instance, if the index doesn't exist, or is blank, getValue might return something else)

Or would it not work like that?

If it does, I think I'm starting to see some usefulness in that for doing things like traversing nested node objects (although there are better ways to do this I'm sure, it just seems like an interesting concept)

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

I'm bad at recursion, so this might take some time.

I think it could be recursive like this, is this what you're thinking?

There is a VectorA that holds objects

Level1: We call Vector_get(VectorA, 1). VectorA[1] is a wrapper object so it's getValue function gets called.

Level2: That wrapper class' getValue function's return is a call to a getter function that returns an "obj" type. So, then that value is unwrapped.

Etc.

This could be exactly what you said, like I said, I'm bad at recursion - I'm a top-down thinker. So recursion isn't my strong suit. I can break things down recursively, but building then up (bottom-up) like this, I get lost, so if I missed it again, please be patient.

_________________
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.

Nope, that's exactly what I meant.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

ok, yeah, i got it, cool. yeah, that works .

Since it sounds like you've got it, and since it's been only us two posting, I'll upload the changed class file. I also made rectangle as a wrapper, which unwraps the width followed by the height (with a space in between), like the example I gave.

Yal can download the latest zip.

Rectangle_test.ahk gives an example of this use.

_________________
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.

Oh, didn't get an answer on this.

The Vector_get (and Array_get) will unwrap even the new wrappers. Should it only unwrap legacy wrappers? Then, add a Vector_getUnWrapped to unwrap all wrappers - still returning the address for non-wrappers. Also, Vector_getAddress can still be used to get the address - regardless if it's a wrapper or not.

_________________
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.

I personally think you should treat all wrappers the same, for consistency. Perhaps add an option to wrapper classes whether or not to unwrap by default (with the default being to unwrap if unspecified)?

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

K, sounds good


Do you mean like a toggle? If so, that won't be added (if I'm thinking what you are thinking). Here's the reason: If you don't want the object unwrapped, use "uint" as the type (for the getter); if you do want the object unwrapped, use "obj". Or, if you want a toggle, have it built into the getter function.

Ex:


This function would unwrap wrappers by default, and return the address for non-wrappers. Then, by specifing unwrap = false, it would return the address - regardless if the object was a wrapper. This ability is already supported, so enjoy. This also allows more fluidity, because the value would be unwrapped or not based on a parameter - no toggle to turn on and off.

If this isn't what you meant, could you clarify?

_________________
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.

I forgot to update the wrappers to return their old value. Now String, Int, etc. return the previous value when setting a new one. Also, Rectangle_setColor didn't return the old value.

These are all corrected in this update.

_________________
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.