New Objects Issue

[1100++]

I just noticed that objects created with the "new" keyword don't work with For-loops (they do nothing). Should this be happening? I don't see anything in the documentation for the For-loop saying that this should be happening.

[swagfag]

post code

[nnnik]

for loops call the _NewEnum() method for this object and use the resulting enumerator object to enumerate over the object field.
If the specific object you created with new overrides this method for could stop working.

[1100++]

Here's my code:

Code: Select all

obj := {a: 2, b: 3, c: 5}
newobj := new obj

For key, value in obj
	String .= key ": " value "`n"

For key, value in newobj
	NewString .= key ": " value "`n"

MsgBox % "Obj`n----`n" String "`nNewObj`n---------`n" SubStr(NewString, 1, -1)

This is the output:

Code: Select all

---------------------------
Code Result
---------------------------
Obj
----
a: 2
b: 3
c: 5

NewObj
---------

---------------------------
OK   
---------------------------

[swagfag]

using new in this manner instantiates the same object as the following would instantiate:

Code: Select all

newobj := {base: {a: 2, b: 3, c: 5}}

to enumerate these fields, either assign ur new obj its own custom enumerator, or iterate over the .base object:

Code: Select all

for k, v in newobj.base

what are u tryna do anyway? maybe .Clone() is a better fit for ur needs?

[1100++]

I have an object that represents an initial state for a simulation I want to run multiple instances of. In order to do this, I need to be able to copy the object for each instance.

[1100++]

I just did a little more testing, and it seems that you can't change a "new" instance of an object without doing the same things to the object it came from. Doesn't that kind of defeat the purpose of a "new" keyword?

[nnnik]

The new keyword is mainly for classes.
To fully learn what it does I reccomend getting a basic knowledge about classes first.
I could give you a minor explination of what exactly happens when you use new and how that changes the object.
However you wont be able to fully use objects without learning classes anyways - so I reccomend learning them first.

[lexikos]

I just did a little more testing, and it seems that you can't change a "new" instance of an object without doing the same things to the object it came from.

I wonder what kind of testing brought you to that (mistaken) conclusion.

To change the new object, you do exactly the same as you would with any object: assign. This does not "do the same things to the object it came from" or affect that object at all.

Code: Select all

x := {a: 1}
y := new x
y.b := 2
MsgBox % ObjHasKey(x, "a") && not ObjHasKey(y, "a")  ; Only x has "a"
MsgBox % ObjHasKey(y, "b") && not ObjHasKey(x, "b")  ; Only y has "b"
MsgBox % y.a " " y.b  ; y inherits the value of a.
y.a := 0
MsgBox % ObjHasKey(y, "a")  ; y has its own a now.
MsgBox % x.a " " y.a  ; x.a is unchanged.

See Custom Objects (first section).

To fully learn what it does I reccomend getting a basic knowledge about classes first.

I do not believe that learning about classes (from AutoHotkey or any other language) is helpful in understanding what new does. On the contrary: learning about traditional (restrictive) class-based design before learning about prototype-based design may delay the understanding of AutoHotkey's objects, since it uses the latter. Classes in AutoHotkey are nothing but syntax sugar, and as such are completely non-essential. To build an understanding from the ground up, I would recommend not to start with classes, but to start closer to how objects actually work (constructing prototype/base objects explicitly, which is what the OP is already doing).

[nnnik]

Learning about classes is not necessary for learning how objects work in every detail. Learning about classes as an abstract concept makes the topic more accessible for new users.
The added abstraction layer will add restrictions - just like you said. The thing I disagree about is that removing these restrictions will help the person in question.
There are many major pitfalls in using dynamic bases, meta functions and all the other stuff.

Also as far as I'm aware classes are the only way to get properties - so how can they be syntax sugar anymore?

[lexikos]

That is irrelevant. If you disagree, explain how understanding "classes as an abstract concept" helps one to understand what AutoHotkey's new operator does.

The added abstraction layer will add restrictions - just like you said.

No I didn't.

[nnnik]

Well I thought that OP had issues with interpreting the results of his experimentations with new rather than new itself.
It seemed like he had trouble understanding the concept of inheritance or in AHK specifically base objects.

Now we could approach this general topic of inheritance (and objects in general) in 2 ways.
You suggest to keep experimenting and interpreting the results to find a specific way to use objects for themselves.
I suggest to learn about classes as an abstract concept and then apply what they learned about how to use objects on AHK objects.

The advantage of the experimentation approach is that it is probably more fun to experiment and will result in greater specialization.
The advantage of the class approach is that this person will be able to use classes in several languages and will probably be able to create good code a lot faster.

In the end both has to be done anyways to create good code easily. It's a question about where to start.
Its essentially the question whether learning about AutoHotkeys specific implementation make it easier to learn about classes than the other way around.

And I think its esier to learn about general classes first.

[jeeswg]

- As swagfag hinted, newobj := obj.Clone() is probably what you want.
- Is 'new' working contrary to your expectations? If so, which programming language(s) works(/work) differently?

[lexikos]

That is irrelevant. If you disagree, explain how understanding "classes as an abstract concept" helps one to understand what AutoHotkey's new operator does.

No explanation, nnnik?

You suggest to keep experimenting and interpreting the results to find a specific way to use objects for themselves.

I did nothing of the sort. I posted code with comments demonstrating and explaining the behaviour, and then suggested to read the documentation for Custom Objects and Prototypes to learn how objects actually work.

It seemed like he had trouble understanding the concept of inheritance or in AHK specifically base objects.

Both of those work differently in AutoHotkey than "in general classes", and neither one necessarily has anything to do with classes, like in the OP's case, which is not a class in any sense.