AutoHotkey Community

Its address changes whenever its capacity is changed. I think it would mostly defeat the point of using the field itself for storage. May as well just allocate memory like I was suggesting earlier. If you want to say .dataPointer instead of ._GetAddress("data"), you could do this:

Update: this has been implemented generically in script.
BinObject

Lexikos,
Is there a reason this is not default behavior:

Do you anticipate any problems if I routinely include this in my scripts?

Also, do you plan to implement: push(), pop(), find(), and friends for objects? Some of this has been done in script by temp01. But these basic things are probably worth implementing in c.

Those two ideas conflict. What happens if code first tries to set a field of the object, expecting it to already exist, then retrieves that or some other field? You'll never get the warning, and if the code wasn't intended to initialize the object it will be more difficult to track down the problem. If an object is expected to have custom methods like push() or pop() but is automatically initialized without them by erroneous code, it'll add further confusion.
My goal was never to provide comprehensive built-in object API's, but to implement the minimum to let script authors easily do it. I do however plan to implement Next/Prev for enumerating fields (see here or here) and make some other slight changes/improvements to the built-in methods.

Functionality equivalent to push/pop can be easily written like so:
Inserting and removing at the lowest index is slower, but since calling _MaxIndex (or any method) in script incurs overhead, this method performs about the same until there are over 100 or so items. This might change if/when I replace the built-in methods with built-in functions (which have less overhead, but might appear less intuitive).

I had considered making _Insert/_Remove equivalent to push/pop (at the highest index) when the key is omitted, but decided it wouldn't necessarily be intuitive. On the other hand, if ObjInsert(obj,value) and ObjRemove(obj) served as push/pop, scripts could do this:
The idea is that if they are built-in functions, object developers can do things like redefining _Insert without losing the original functionality, or use the functions on objects which would otherwise override the built-in methods (such as COM_L/U objects).

Actually, I didn't want to introduce more functions/methods with virtually the same purpose. For instance, obj._Remove(x) would be more useful if it returned the previous value of obj[x], then obj._Pop() would be no different to obj._Remove(obj._MaxIndex()) or similar. However, it might be worth doing - if only so that scripts using them will be easier to understand. (It can be done/has been done in script, but you might be right about it being worth implementing natively.)

Last ranted by Lexikos on Sat Jan 02, 2009 8:00 pm; edited 101 times in total

1. That is consistent with the the old ways of ahk, but I do like the way that the error checking is now possible and optional.
2. I wonder if you define a new type such as binobject, you could also define a meta function: binobject.is(UFO) that checks if the metafunctions match.
3. But I don't see a necessary conflict, just replacement of some error checking, which is fine as the behavior is set in script and can be changed between debug builds and production builds of your scripts...
4. The problem with the current way is that if nonobj is not initalized, the following fails silently:
nonobj.member := "hello" ;
Anyway, I am happy with my script solution, adapted from your documentation.

Thanks for the nice analysis of the situation. Edited 101 times really?

You're going to find yourself atleast implementing list processing functionality, otherwise objects will remain even less efficient than lisp. For example Fasto reimplemented my ahksearch using objects, but reported "consumes a lot of resources".

One thing that might help is special treatment for multidimensional rectangular objects. I have not seen any examples for usage of Object._SetCapacity(new_capacity). What is the default size of the individual elements? ie:
how many elements can you store if capacity is 256? Is it 4 ? The default capacity of variables in ahk is normally 63...

LowLevel had allowed access to the var interface, but I also liked access to var contents with the native &var. On the contrary, with objects, we don't have access to contents, and &object gives access to the interface...

How about a metafunction object._ascontiguousarray, that goes along with
Object._SetCapacity(element_size, number_of_elements).

On a second read, I can get my head around the source code a little better...

Lexikos,
What do you think about splitting up the Object::FieldType structure into 2 or more parallel arrays, so the keytype, keys, and values can be kept in separate arrays ?

get and assign don't need to become more complicated as the index of key and its corresponding value will be the same, although in different arrays.

I disagree. Think of it like NumPut or some DllCalls, which won't work if the variable hasn't been initialized in some way.
Why would a new type need to be defined to build-in that functionality? Why not merely compare them yourself, in script? Why compare them at all?
You cannot catch all such errors and automatically initialize objects in variables. I stand by my use of words. Anyway, you asked why it wasn't the default behaviour, and I answered. It's your choice to use it or not; in fact, that's why I implemented the "default base" feature, and obviously the reason I put those examples in the documentation.
What problem? This is consistent with "the old ways of ahk;" at least for expressions. Take (var+=1) for instance.
Speak for yourself.
I'm always skeptical about apparently baseless claims of performance. I'd ask you to show some facts, but to be honest I'm not interested.
I'm certain that fasto wasn't referring to speed. Notice the SQLite example; which is "a bit slower".
I chose the current implementation because it is simple, useful and works for all types of keys. I see no specific need to optimize it soon, if ever. Anyway, it has nothing to do with efficiency of objects in general, so I don't see how this "one thing" "might help".
If you set the capacity to 256, you can store up to 256 "elements" before the capacity must be increased. Objects hold key-value pairs, not characters or bytes.
FYI, individual key-value pairs (elements) are currently 16 bytes. String keys and values are allocated separately, as necessary. If _SetCapacity is not used, the capacity of an object begins at 4 (on first assignment) and doubles when a higher capacity is needed. This is all subject to change.
Variable capacity is measured in characters, and in fact, you're wrong.
Where do you think the interface is, if not in the Object? In fact, &object is currently both the address of the Object and the address of its IObject interface. I had not mentioned this as it is obscure and the structure is more likely to change than Var, Line, Func, etc. If there is really a need to access it directly, a built-in feature of some sort should be implemented to alleviate it. (Then again, maybe allowing it will allow scripts to "prototype" useful features.)
Why?
There would be no benefit in allowing scripts to specify the size of an element, as it is not something that can change/be changed at run-time, and it shouldn't be relevant to scripts.
Why?
They don't need to become more complicated; I can I leave them the way they are. If you're trying to say that splitting the keys and values won't complicate the code, I disagree.
Oh yes, really.

> Think of it like NumPut or some DllCalls, which won't work if the variable hasn't been initialized in some way.
ok.

> key-value pairs (elements) are currently 16 bytes.
> &obj + 8 -> pointer to first field
Thanks.

If the values were in their own array, they would already be contiguous.
contiguous arrays are easier to pass around (to disk, to foreign functions in dllcall). This is particularly useful in numerical, graphical computing. But I guess for those purposes its already a waste to make an obj.element out of every pixel or every matrix entry. I think binobject is sufficient, so never mind.

They already are in a contigous array; it just includes more than simple untyped/statically typed values. What reason is there to (re)move the keys? I doubt it can outweigh the benefit of being able to treat each key-value pair as a single unit (FieldType).
Funny you should say that. One contiguous array of fields is easier to deal with than two contiguous arrays; one of keys and one of values.
Writing to disk, you would need to check each field for a separately allocated string, deal with objects, etc. It would also include the symbol (type of value). Passing to foreign functions is no easier either; you still have the symbol, have to handle different types of values in the array, etc.

Btw, you said before "keytype, keys, and values", but key-type is not stored in the array. Only the key, value and type of value are stored. To save space, the type of key is implied by the field's position in the array and the object's mKeyOffset* fields.
I imagine in such a case, you would want to use a (less) specialized data structure, without any keys and with only a single value type (so no need to store the type of value).

In the Debug example from the documentation, the warning gets triggered by assigningments for Set and Call, but simply re-ordering the meta-function assignments fixes it:



Btw, thanks for OO features - love it.

Thanks, I've changed the example (for the next release). There are a few more ways it can be written:

Actually, "".base triggers __get, not the assignment. Additionally, Object(...).base ordinarily triggers __get as base is built-in, not usually a key stored in the object. However, in the example below x.bass triggers __get but x.base does not:

First, I really like this OO stuff - and worked a bit with it. Thanks Lexicos.


hope this wasn't asked before:

Is it possible, to get a event, when a property from an object is changed? As I understand, its only possible to catch the creation of a key-value pair with the "__set" event, but not the changes (if a existing key is updated).


For example: I have a "thumb" class, wich contains all infromation of a bmp - also, there is a function in this thumb class, who can build the bmp:



Ok, thats the "class" (in fact, the base object). Using example:



That works so far - but, it would be much nicer, if the createbmp() func would be automatically called, if something in the color or imgpath property changes.


I tried to use the standard __set and __get events with a trick to bypass the creation of the real key-value pair:

With the example above it works - because I dont set the real key-value pair - instead I set a second one with the "__" prefix.
If this above is used as base, the following line:

doesnt store "test" in the key "name", it stores it in:


And the same thing is done, when using get:

This doesnt retrive "name", instead it retrives the "__name" key.
But thats a nasty trick - how can this be done better?

Hope someone can help


Edit:
If someone wonder, what that thumb stuff should be: here my testing with a oo ThumbnailViewer: http://dl.securityvision.ch/ahk/thumbnail/thumbs.zip

_________________
http://securityvision.ch
AHK 2D GAME ENGINE

You could wrap your object into another object, and define meta-functions for the wrapping object. Then the set meta function can both update the wrapped object and do other stuff. Perhaps that's a bit cleaner than your current solution.

Haven't tested this heavily, but something like this I imagine will work:

I had a simple technique in mind for defining "accessor" functions, but unfortunately it doesn't work as intended in the current version. I'll update soon with a fix, after I push some other updates out.

The technique looks like this:
Example usage (hackfix() lets it work in the current version):
The idea is that instead of writing meta-functions with big If..Else If ladders (determining which property is being accessed), you simply define which properties correspond to functions.

Note: Meta-functions are designed not to be invoked if the key-value pair already exists, since to do otherwise would require the __Get or __Set fields to be looked up every time any field in the object is accessed, if that object has a base. "Inheritence" would also be more complicated to implement.

Thanks for your replys.

I understand - so this would be bad for the performance. The accessor technique sounds very usable, so I'm looking forward to the next update.

_________________
http://securityvision.ch
AHK 2D GAME ENGINE

Hello.

What are your plans on xdc. ?

_________________