AutoHotkey Community

Both/either. Will it cause problems if not a Class option? If not, just remove it and I'll remove it in Node.ahk and reupload the files, thanks.

_________________
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 don't see any issues with it not being a class option; I don't have any immediate needs to create a method called constant() in my classes, and if I did, I could change the name slightly to adjust, since I'm planning to use constants in many of my classes now anyway.

I'm still working on converting a few of my classes over before I test, but I like the new methods.

Just to confirm, is this valid for the BuiltInValues variable in getBuiltInValues?

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

K, thanks for the feedback. I changed the Node.ahk and uploaded the updated version. Of course, you don't need to redownload it.



If "b1" sets an "obj", "b2" a string, "b3" an "obj", etc., then yes. Exactly what you need to do. You can also, optionally, have comments on the right-hand side - so that you know what the values represent. See Rectangle/Rectangle_test for an example of this.

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

Critical update:
I accidently copied the lock count when cloning an object. This update fixes the problem and initializes the clone's lock count, correctly, to zero. Download the updated zip.

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

Thanks for the update. Constants are working great. Now instead of remembering that DOCUMENT_NODE_TYPE maps to type 11 and ENTITY_REFERENCE_NODE maps to type 5, I can just call the constant

Haven't tested clones yet, but it sure did shorten my cloneNode functions in my DOM implementation!

Very cool.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Glad to help.

I'm assuming that you don't ever check the built-in size or user-defined size using their class functions (as I haven't given the "go ahead" on them). I'm going to modify the New function a little, because right now, there is a limit of 63 words for built-in values - because the values are in bytes. I'm going to instead store them in words. This will allow up to 255 built-in values to mimic the 254 limit on user-defined. It's only 254, because -1 (i.e. 255) is reserved to state that the capacity is the "user-defined size" (used by Array and Vector). This allows them to grow up to 4.3 billion values (give or take), instead of just 255.

Don't worry, it will be backward compatable. Also, your classes that use 30 bytes (or other non-multiples of 4 bytes), will be bumped up (to the next word). This won't matter, since the remaining 2 bytes were lost anyway. I was just thinking that you said it made more sense to use words, and I agree. I just figured out how to do it, make the code a little neater, and still be backward compatable. I won't be releasing this update until the site is finished (which should be soon - just a little more copying and pasting left...). I mean, I need something to unveal with the site.

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

Any good way to enforce read-only values?

For some nodes, I'd like to create it with certain values, and then not allow them to be set again. Not sure if that's possible, or if I'm just going to need to instruct users not to directly set values and to use the helpers instead?

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

We are talking about the constants, right? I thought you might ask for them. I'll change the structure to allow them.

Which should be the default, readOnly, or readWrite? There will be a second list which would be set to the variables NOT using the default method (this way it's a smaller list). Also, the values on the second list still must be on the first list (the variables list). The variables list will be used to see if the passed variable is a stored variable. Then, the second list will instruct if a value can be set. If the value is "read only", then even when a setValue is passed, the value will remain unchanged.

How does that work? Just tell me which to use as the default and I'll have it up in 10 or so minutes after that (maybe 15... testing, you know).

Update, or do you mean built-in values...?

_________________
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 meant built-in values, but both would be handy. For constants, the method you described sounds perfect.

I think read/write should be the default for both, but I can see where it could come in handy to want read-only built-ins as well as constants.

Unfortunately you still have to set the built-in once, so it would require additional logic.

The DOM specification is riddled with attributes that should not allow the user to set them after the object is created.

I supposed I could just remove the Setter for read-only parameters and put the contents of the function directly in the _new() call for the object to set those values?

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Well, constants is an easy fix, I'll add that and upload it.

For built-in values, that will be tougher. Now, there are readOnly (like constant) and readOnly (write once).

For example, in most programming languages, a constant variable MUST be declared when defined. So, you could set the value in YourClass_New, and don't create a set function for it.

The second, a write once is harder. This would, I believe, require a bit flag to be stored along with the class. It would be initialized (automatically) to zero when the object is created (i.e. not set). Then, when you call the set function, you would first check that it is unset. Then, you would set the value, and set the bit flag to signify the value is "set". If you want to use this method, tell me and I can post some details after I upload the changes to the constant function.


However, neither of these methods are actually read-only. The user can still edit the values (using NumPut and figuring out the memory address). Heck, easier - change the source code. My opinion, because there is no such thing as private functions / variables in AHK, I would just tell the user what they can and cannot do. For example, if someone wanted to, there is a Vector_setSize function; they could change this value to any value they want. The problem mainly occurs when destroying the Vector. If the set size is smaller than the actual size, then there are some objects that aren't destroyed; set more than the object's capacity causes buffer overflow, which would probably crash the code. I mean, this Class library is NOT set up to be secure - but that's because AHK isn't designed like that, personally, I like it. Less fuss and overhead - just don't write a banking program in AHK .

Either of these methods can be currently used. I cannot think of how to add this support to built-in values without storing something in the object. The "constant" value, there is no set - no worries. The other would require something stored in the object to say "you have already set me, you can't do it again.", or "you haven't set me yet, feel free to do so.". You can add this bit flag yourself.

Now, for the constants, I can add that feature easily - since the values are shared by all instances of the class. So, readOnly means initialize, but don't change. I'll get that up in a few minutes.

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

Sounds good; read-only constants will be nice.

I think it's perfectly acceptable to implement read-only values in the class itself, so I'll work on doing it on one of my classes and see how that goes. I'm hoping to find a way that doesn't add a lot of overhead. Barring that, I may just change the set functions for read-only values to indicate that they're supposed to be private.

I don't so much care about keeping users from modifying the values, but I'd like to be fully DOM compliant, which means at the end-user script level, the read-only values should not be able to be set by the normal method (or should throw an exception if a user tries to write them). For actually throwing the exception, I think I'd need to use a bit flag per set-once value, as you suggest.

Not sure if it's worth it yet to be DOM compliant or not, however

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Ok, here is the updated zip which allows read-only static constants. Check the Node class for the changes.

When you figure out read-only built-ins, mind sharing? Also, some words of caution. You can't use a static variable to track if the value has been set, because the value can be set once in each class (not just once, period). And, if the same value is used in all the classes, then make it a constant instead of a built-in. Caution aside, good luck, and I'd love to hear how you do it, so that I could include a footnote on the website(appropriately credited to you) on how to set read-only built-in values.

_________________
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'll let you know as I figure out how I'm going to try and do it. I think it'll be some sort of utilization of bit flags in the object, as you've suggested.

As a side node, I figured out an interesting way to handle Node inheritance in my DOM library.

The DOMNode class is inherited by all of the main node types, which are what actually builds the DOM tree. Each of those types has a nodeObject built-in, which references a "child" DOMNode object, storing the inherited values.

DOMNode's methods need to be able to work both on its own DOMNode object, and the parent object's values.

I don't always know whether the object passed to DOMNode is an actual DOMNode, or an inheriting object (such as DOMElement, which has a nodeObject attribute).

So thanks to the magic of the Class library, I was able to write two simple functions that can be used where I specifically need a DOMNode or a parent object, no matter what is passed:


Nothing special, but it's very cool how simple things like this are now.

While it's still not true inheritance, I'm at least able to make it (basically) completely transparent for the end user.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Awesome. Glad you're a fan of my magic show - I'm here all week .

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

Hmmm...

Is it possible to tell if two objects are equal, even if they are not the same object? For instance, if I wanted to pass a clone and its original object to determine if they are still equal?

It would essentially get every built-in and user-defined value and compare it to every built-in and user-defined value of the other node, I think.

Is there a way to do this other than adding a function to each class that needs it which gets each value from each object and compares them manually?

I'm thinking since V2 classes store their value types, the Class library would know how long every value is and could iterate through them faster than the end class could. Maybe not, though.

--

It looks like Python keeps a list of ReadOnly attributes for the DOM library, and checks against that list when setting the value. I would still need to figure out set-once values, though. Maybe the _new() function for the object would bypass the read-only check.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music