[Wish:] Wish value properties could have the same name as methods even both owned by one object Topic is solved

[V2User]

Currently, method is method. Method will never overwrite value property/dynamic property.
Below codes will output "value property" as usual, unaffected by any duplicate names of methods:
Code1:

Code: Select all

class CCC {
	p:="value property"
}
c:=CCC()
c2:={base:c}
c2.DefineProp('p',{call:(ths)=>89})
OutputDebug(c2.p)

Also currently, dynamic property is property. dynamic property will never overwrite method.
Below codes will output "method" as usual, unaffected by any duplicate names of dynamic properties:
Code2:

Code: Select all

class CCC {
	f(){
		OutputDebug('method')
	}
}
c:=CCC()
c2:={base:c}
c2.DefineProp('f',{get:(ths)=>OutputDebug("Property")})
c2.f()

But currently, value property will overwrite method with same name, unlike how dynamic property or method behave.
Code3:

Code: Select all

class CCC {
	f(){
		OutputDebug('method')
	}
}
c:=CCC()
c2:={base:c}
c2.DefineProp('f',{value:89}) ;Cannot use c2.f:=xxx currently.
c2.f() ;Method is overwriten by property and throw.

In Code2, if you want to clearly overwrite the method f and run, you always can write c2.DefineProp('f',{call:ths=>OutputDebug(2)}).f().
But currently you can also write c2:={base:c,f:ths=>OutputDebug(2)},c2.f().
It doesn't make sense to offer two ways to achieve the same goal in this situation. Method for overwriting method, callable property for temporary use, seem more reasonable. callable property will only get used, only when samename-methods don't exist in c2 and its bases or are deleted.
Why not to unlock it that all kinds of properties could have the same name as methods even in one object? It is backwards compatible to achieve this. It's just purely something of unlock. It has no side-effects to existing codes as well as the existing DefineProp(free to allow call and value/get,set to be together in Desc).
Slow down the performance? when method is not defined in prototype? I surprisingly cannot find any shortages for this wish at this time.

[Descolada]

Other than creating ambiguity where there was none before, and creating more possibilities for making errors in the code, what good would this change bring? I would think there are good reasons that multiple programming languages (eg C#) don't allow this.

Since AHK allows executing functions without any parenthesis, what would be the expected result in this case:

Code: Select all

class A {
    f := 1
    f() => 2
}
A().f

You might argue that in such cases parentheses would be required to resolve the ambiguity. How about this case then:

Code: Select all

class B {
    f := MsgBox
    f() => OutputDebug
}
B().f()

[V2User]

Other than creating ambiguity where there was none before, and creating more possibilities for making errors in the code.

Some one who expects to call methods will call methods. Some one who use properties will truly use properties. Methods/dynamic properties called without parenthesis in current codes will forever get called in this. Properties called as a method without parenthesis in current codes will never define a same name method again in this version, because someone has treated the property as a method. With all due respect, this is not ambiguous as imagined in my personal opinion. They will probably not interfere with each other.

Code: Select all

class B {
    f := MsgBox
    f() => OutputDebug
}
B().f()

B().f() always run method containing Outputdebug. (B().f)() to run property.
If it creates any ambiguities or chances of making errors by value property f := t=>MsgBox() in above, then the same will apply to current dynamic properties:

Code: Select all

class B {
; Code in current version
    f => t=>MsgBox()
    f()=>OutputDebug
}
B().f()

I surprisingly cannot find any shortages for this wish at this time.

If there is even one worse compared to current. I will apologize for posting.

what good would this change bring?

Other than unlocking the namespace, there aren't many good left. But it has.

[lexikos]

Please read the documentation and check your assumptions. One object cannot own both a value property and a method with the same name.

The ability to define functions to be called for each operation (get, set and call) is a feature, and will not be removed. Allowing a getter and a method with the same name to be defined in the same class is an extension of this.

Also consider backward compatibility when you suggest changes.

[V2User]

Please read the documentation and check your assumptions. One object cannot own both a value property and a method with the same name.

I am sorry for I haven't express that clearly. Therefore I've changed the title just now.

Why not to unlock it that all kinds of properties could have the same name as methods even in one object?

This above has also been changed which represented the wish.

The ability to define functions to be called for each operation (get, set and call) is a feature, and will not be removed.

Yeah, I never wish to make any remove on get, set and call, but to extend.

Allowing a getter and a method with the same name to be defined in the same class is an extension of this.

Only change above into below:
"Allowing a getter/value and a method with the same name to be defined in the same class is an extension of this."
Since you have made an extension, how matter to extend again.

Also consider backward compatibility when you suggest changes.

Maybe it's not actually a change. Maybe the formal existing codes will not get changed if you apply the suggestion this time. Maybe it is more properly an unlock than a change. If you only update the interpretor with this suggestion but without updating document, maybe no one feels and knows it, until you tell him what more he can do. It's quite compatible with the current DefineProp, OwnProps as well as getMethod.
Currently, some one will often use m1:=obj1.Method1 to get a method func object from obj1. However, he will never use m1:=obj1.Method1 to get method, if there is a getter named Method1 at same time in current code. He will use getMethod instead. The same also seamlessly applies to this feature which I advised in the post.
Making properties extend to share the same namespace will not be a large thing, will it?

[lexikos]

I do not know what the nature of the eight(!) edits to your original post are, but you still seem to be under a misunderstanding.

Method will never overwrite value property/dynamic property.
...
But currently, value property will overwrite method with same name, unlike how dynamic property or method behave.

There are only two kinds of properties and one namespace:

There are value properties and dynamic properties. Value properties simply contain a value. Dynamic properties do not contain a value, but instead call an accessor function depending on how they are accessed (get, set or call).
Source: Object - Methods & Properties | AutoHotkey v2

What you are calling a "method" is a dynamic property with a call accessor. This is quite obvious when you are using DefineProp {call} to define it.

When you define f() => in a class and then define f => on an instance of the class, the properties are owned by two different objects.

A value property implies all three operations: get the value, set a new value, and call the value. An object which inherits a value property inherits each of these operations independently. If the derived object defines call, that may be combined with the operations inherited by the value property. If the derived object defines a value property or all three operations, it cannot inherit anything.

Changing this so that an inherited call accessor function takes precedence over a value property would break existing scripts. It would also reduce performance, since every time you look up a value property to be called, the program needs to keep searching up the entire chain of base objects to ensure there is no call accessor function.

When you define a method with this.DefineProp(name, {call}), it will overwrite any value property owned by this. If there is a dynamic property, it will only overwrite an existing call function, while retaining any get or set.

To overwrite a property is to replace it with a new property or value. When a derived object loses access to a base object's property (no longer inherits it) due to a new property being defined in the derived object, this is called shadowing or overriding, not overwriting. I am not sure that you are correctly making this distinction.

Adding the capacity for a dynamic property to also hold a value would be entirely redundant, and may increase overall memory usage or code complexity. It would also cost me time to develop and document. I don't see the benefit.

A trivial way to achieve the same effect is as follows:

Code: Select all

x := DefineValueMethod({}, 'f', 41, this => MsgBox(this.f))
x.f() ; 41
x.f++
x.f() ; 42

DefineValueMethod(obj, name, value, method) =>
    obj.DefineProp(name, {
        call: method,
        get: (this)     => value,
        set: (this, nv) => value := nv
    })

"Allowing a getter/value and a method with the same name to be defined in the same class is an extension of this."
Since you have made an extension, how matter to extend again.

By "is an extension of this" I mean "is due to this". A dynamic property has get, set and call functions. A property definition sets get and/or set and a method definition sets call, therefore they can all coexist. A value property is not a dynamic property; they cannot coexist.

Since AHK allows executing functions without any parenthesis, what would be the expected result in this case:

The expected result would be nothing. A is constructed without side-effects, f is retrieved without side-effects, then the instance of A is deleted.

A().f is not a method call statement. It is the same as x := A().f, except that x is not defined.

Parentheses can also be omitted when calling a method in this same context, but only when the target object is either a variable or a directly named property, such as myVar.myMethod or myVar.myProp.myMethod.
Source: Scripting Language | AutoHotkey v2

If you instead used

Code: Select all

x := A()
x.f

the expected result would be that the method f is called.

If there was no method f but only a value f = 1, this would throw an error because 1 can't be called.

How you define the property has no impact whatsoever on whether this tries to call f or get it. That's solely dependent on the syntax.