AutoHotkey Community

It is currently May 26th, 2012, 3:12 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 259 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 18  Next
Author Message
 Post subject:
PostPosted: March 6th, 2009, 8:03 am 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
Yeah, there is. I'll add that. I'm calling it a night, so I get to it tomorrow. The function will use V2 design (using the BuiltInValues and UserDefinedValues function, like destroy and clone). So, sadly, it won't work for your older classes until you update them. How about calling the function "equals"? This is the name used in java. Also, this will then become part of the class standard. Since every class should be V2, the equals function will be a simple function call - one line function.

The function will first compare the class names - make sure the objects are the same type. This will also make the comparasions make more sense. Of course, like clone, it would dynamically call YourClass_equals, so you could implement the equals differently if you had to.

The idea I'm thinking is to first compare the class names. If they match, continue, else return false (i.e. not equal). Then, compare value-by-value. The only problem is if a pointer to an object is stored (i.e. "uint"), then the pointers would have to match (i.e. the pointers are compared, not the object). I'm not sure what to do about this. Would it make sense to compare them as uints (like they are stored), or should I think of how to modify the Class design to allow stating that they are actually objects in disguise?

If a change would be done, I think a new type would do the job - "ptr" (pointer). This would signal that the specified object is stored as a "uint", but is a pointer to an object (versus a normal uint). Also, then the getter and setter both would be "ptr" instead of the setter being "uint" and the getter being "obj". Of course, you can still specify the getter to be "uint" to return the address for the object. Does that work? Plus, I guess the class library should know what is a number and what is a pointer to an object. Now, just because it's called "ptr" doesn't mean you need to use "&" to get the address - it's just a notation used by the class library.

For destroying "pointers", since they are stored as a number, there is no object set (i.e. the lock count isn't modified), so it will be set to zero as if it were a normal uint. Likewise, since it is just a pointer, the clone would use the same pointer value (once again, it's not an object, merely a reference to one).

This change will be backward-compatable, but required to compare the object instead of just the pointer (if you used pointers to objects that is). Also, I'm going to be adding a Comparable class option. This would use a compareTo function - YourClass_compareTo(Object1, Object2). This would allow classes to have an "ordering" (which is required to add sorting). This is still bouncing around in my head - not sure what needs to be done for this. I'm going to add it shortly though. Sorting will get in eventually. After everything is setup, I'll start figuring out how to best implement a sort for Array and Vector.

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 8:15 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Awesome, thanks!

I think a "ptr" object would be excellent, and would allow separation, as far as Class is concerned, between object references and actual integers, as you stated.

I also think it would be less confusing to think of object pointers as separate than numbers when developing. Sometimes it takes me a second to remember what I'm working with :)

No rush, it's just good to know it will be implemented

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 8:35 am 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
bmcclure wrote:
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.

Well, true constants would be initialized when creating the object, right? So, these would be put into YourClass_new. For set-once, you can use bit flags and check them in the setter. Since each char (1 byte) can store 8 bit flags, you should be able to have enough for your needs without wasting memory. Also, since bit-flags modify / retrieve a single-bit at a time, you can easily check if the value is set and set it.


Here's an example. It only looks bloated because the comments

Code:
YourClass_setFunction(YourClassObject, setValue)
{
    ;"b1" would store the read-only bit flags (as a uchar)
    ;this would leave 3 bytes of that word for your needs - a short, some chars, etc.
   
    ;since this function sets a word, we will start at "b2"
    ;I would presume we could store a word starting at "b1a", but it looks weird to me
   
   
    ;check the read-only bit for this value ("b1-1")
    if !Class_getValue(YourClassObject, "b1-1", "uchar")
    {
        ;since it hasn't been set yet, we can set the value
       
        ;set the read-only bit for this value (since it's a write-once value)
        Class_setValue(YourClassObject, "b1-1", true, "uchar")
       
        ;you can either return the setter's return (the previous value) or your own
        ;also, you can specify the type (this call uses "uint" - the default)
        return Class_setValue(YourClassObject, "b2", setValue)
    }

    ;value was set once, return a value of your liking
    ;I chose the previous value (for consistency)
    return Class_getValue(YourClassObject, "b2")
}


I could also shorten this a little with a wrapper for read-only. It would only shorten it by a line. It would, however, allow using the ternary operation.

Code:
YourClass_setFunction(YourClassObject, setValue)
{
    return Class_canWrite(YourClassObject, "b1-1", "uchar")
        ? Class_setValue(YourClassObject, "b2", setValue)
        : Class_getValue(YourClassObject, "b2")
}


Class_canWrite would return true (1) if the bit flag is unset (0), and return false (0) if the bit flag is set (non-zero). Also, if unset, it would automatically set it before returning. Then, you can use the ternary operation to set your value or return a different value if you cannot set it. Of course, if you didn't return the previous value (the return from setValue), then you couldn't use the ternary operation, but at least you don't have the headache of the bit flag.

Like the first function, "b1-1" is the read-only bit flag for the specified value ("b2"), and "uchar" is the type that it is stored as. For example, you can store bit-flags in char, uchar, short, ushort, int, and uint types - number of bit-flags based on type. Unsigned versus signed only matters if you ever return all the bit flags at once - ex. Class_getValue(YourClassObject, "b1", "uchar"). I use unsigned, just because I'm used to it. Either behave the same way when used as bit-flags. You cannot use float, double, UInt64 or Int64 though. There is no check, just this warning (which will also be on 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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 8:39 am 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
So should pointers be compared as numbers or objects? Let's say I have two objects (same class) that each have a pointer value. Even though the pointers are different in value (as uints), but point to equal objects (as checked using the class' equals method). Should the value be considered equal only when the pointers matched (as uints), or should their respective object be compared?

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 4:10 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
I think the default in that case, is that their respective objects are compared, to effectively check if the pointers' objects are equal, too.

However, I can definitely see an advantage to doing it either way.

I'd hate to make it too bloated, but how about an additional parameter, somewhat like 'deep' for clones, that will decide whether to traverse into pointers to check, or just compare their pointer value?

--

And thanks for the help with using bit flags for read-only values! I hadn't used bit flags yet, but it does look quite simple. I'll implement your suggestion in the DOM class I'm working on and see how it goes.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 8:06 pm 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
Adding a parameter wouldn't do the job correctly, because you'd have a mess. Also, when comparable gets added, it will just be worse. However, I can see the benefit comparing either way, so how about two pointer types. "ptr" will be a "deep" compare, because you say the default should be deep, and I'll think up something for shallow. I'm thinking "sptr" (shallow pointer), if that's not too confusing. Both are stored as uints (like all objects), but they instruct that the value stored is a class object. They differ from "obj" because they will not modify the lock count of the object when being set or re-set. So, in almost all behaviors, they act like an uint.

"Pointers" differ in that:

1) They provide feedback for the desginer (and user, I guess) that the specified value is not a normal uint, but a pointer to an object
2) They can be treated as objects by the class library when appropriate.


For example, both "ptr" and "sptr" when used as a setter will store the value as a uint (a pointer to a class object). However, when used as a getter, they function as an "obj" unwrapping wrapper objects or returning the object's address (for non-wrappers). If you want to retrieve the address instead of the unwrapped object (for wrapper objects), use "uint" (the default) as the type. So, nothing will change in this area. Also, when testing for equality, they dictate how they will be compared. A "ptr" will do a "deep" compare. It will compare the pointer's object (not just the pointer) for equality. A "sptr" (shallow pointer) will only check if the pointers match (i.e. as a uint value). Of course, there will be some small performance mods by checking the pointer first (even for "ptr"), because if the pointer matches, the object does (so there is no reason to recursively check it). However, these will be transparent to the user (and class' designer for that matter).


On a side note, I'm glad that the bit flags can be of use. This release will also have the Class_canWrite function (previously discussed) which should make the code a little more managable for your read-only values. Of course, it is your responsibility to dedicate space for the bit flag, but that's an easy task. I'll get these updates out shortly.

Edit:
Forgot to mention that both "ptr" and "sptr" will copy as if they were uints in the clone. Since they don't represent an object, but a pointer, it makes no sense to clone them as objects (use "obj" if you want them to be treated as an object). Likewise, in destroy, the are treated as uint (because to the code, they are stored as a uint - with no side-effects).

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 8:29 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
That sounds excellent. I once again can hardly wait to test the new features :)

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 9:15 pm 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
Cloning doesn't work. I did something when updating the code. Found the problem and it's fixed. This fix will be included with the new update, sorry about 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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 9:27 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
No rush. I haven't started actually using it yet, but since I know the syntax I'm implementing it in the DOM library, which won't even be testable for a couple days.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 6th, 2009, 10:46 pm 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
I just realized that there are options on how to compare strings (case-sensitive and case-insensitive). So, I'm thinking that the best way to accommodate this is a new type for string. This type is only used in the getBuiltInValues and getUserDefinedValues functions (since they don't affect the string itself, only how it is compared). Meaning, you can keep using "string" in the setters/getters. I will add "SString" (case-Sensitive String) as a recognized alias for "string", so that you can use it in the getters and setters and it will function like "string". This way, you can see at a glace which strings are compared as case-sensitive and which are case-insensitive. If yal can think of something better than "SString", I'm taking requests. Just a note, I use a capital for clarify, but all types are case-insensitive, so "sstring" works too.

"SString" is used to compare strings using case-sensitive comparasion: String1 == String2

"string" (the existing type) is used to compare strings using case-insensitive comparasion: String1 = String2

the method of insensitivity depends on StringCaseSense


I'm also trying to figure out what to go with Vector_indexOf (and the others), since it currently uses case-insensitive (Value1 = Value2) comparasion.

Edit:
I'm also going to add a new wrapper object SString. This would function the same way as String, but would use case-sensitive comparasion. Also, a String and SString object are "equal" if their wrapped strings are equal (case-sensitive). Or should String and SString always be unequal, since they are different classes?

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 7th, 2009, 2:09 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Sounds good to me. Case sensitive string matching will be an important feature of the DOM implementation! :)

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 7th, 2009, 2:14 am 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
So I presume case-sensitive and case-insensitive strings should be comparable. They will be considered equal only if they are equal using a case-sensitive compare. This will apply to both the basic type ("string" and "SString") as well as when comparing their wrappers.

For example, if we had two Vectors, each size one. Vector1's element is a String storing "Hello" and Vector2's element is a SString storing "Hello". These two vectors would be considered equal. However, if either string's had different cases "hello" comparing to "Hello", then it would be false.

Edit: should the different number wrappers be comparable to eachother? Ex. a Char that wraps 5 equals a UInt that wraps a 5.

Update:
I'm checking out how java does it with their wrappers. Java does NOT see a Integer(5) equal to a Byte(5). I'm verifying this by checking the code. However, I can implement it either way. Requiring the Same class would be easier though - less internal work, but not enough to make a difference though.

Update2:
Checked the java code. It does do a class check. So, which do you think is best?

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 7th, 2009, 2:49 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Go for the class check. It'll stay lightweight, and really, even though we think of them as the same character unwrapped, I think they should be seen by the language as two separate beasts.

For the need of comparing different object types, I think it's appropriate to unwrap them and compare the unwrapped values.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 7th, 2009, 2:53 am 
Offline

Joined: November 4th, 2008, 9:23 am
Posts: 1045
bmcclure wrote:
Go for the class check. It'll stay lightweight, and really, even though we think of them as the same character unwrapped, I think they should be seen by the language as two separate beasts.

For the need of comparing different object types, I think it's appropriate to unwrap them and compare the unwrapped values.

Huh? To clarify, should it treat equal unwrapped numbers as equal? Int(5) equals UInt(5) equals Char(5)? Also, should String("Hello") equal SString("Hello")?

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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 7th, 2009, 2:55 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
No, I'm saying as far as the Class library is concerned, they should be treated differently, since they are different objects.

If the user wants to compare the unwrapped values instead of the objects, I think it should be done manually. Or there could be some different way to do it.

That's my opinion on the matter at least. Was that clearer?

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 259 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 18  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: IsNull and 0 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group