Code: Select all
Array := '' ; overwrite
arr := [1, 2, 3]
MsgBox arr.Length ; still correctly displays '3', despite having been supposedly overwritten
Code: Select all
Array := '' ; overwrite
arr := [1, 2, 3]
MsgBox arr.Length ; still correctly displays '3', despite having been supposedly overwritten
Code: Select all
#Warn ClassOverwrite
; warns u that 'Array' is about to be overwritten, hit OK
Array := '' ; overwrite it!
arr := [1, 2, 3]
MsgBox arr.Length ; still correctly displays '3', despite having been supposedly overwritten
Code: Select all
#Warn ClassOverwrite
; warns u that 'MyClass' is about to be overwritten, hit OK
MyClass := '' ; overwrite it!
mc := new MyClass() ; "no object to invoke", which is expected
class MyClass
{
}
Code: Select all
#Warn ClassOverwrite
; warns u that 'Array' is about to be overwritten, hit OK
Array := '' ; overwrite it!
arr1 := [1, 2, 3] ; function shorthand
MsgBox arr1.Length ; still correctly displays '3', despite having been supposedly overwritten
arr2 := Array(1, 2, 3) ; function
MsgBox arr2.Length ; still correctly displays '3', despite having been supposedly overwritten
arr3 := new Array(1, 2, 3) ; class constructor, "no object to invoke"
Code: Select all
Array := MyArray
Code: Select all
F() {
Local
Isobject [] ; ?
}
One problem would be if the overridden array.new() were defined to be variadic, it wouldn't work.Helgef wrote:I don't think it's important to be able to completely override the array class, but if it would be possible, I think changing array.new() would be the way to allow it,
Code: Select all
Array := MyArray
MyArray := UrArray
Me neither.I cannot comprehend as to why we would overwrite all instances of array
"If you want to eat all apples, it makes sense to eat an apple." I mean yes, I suppose it makes sense to you, to do something you want to do. But that's not saying much.If you want to overwrite all instances of the class it makes sense to overwrite the instance of the class.
Unless I remove the new operator... or you use any one of several built-in functions that create objects for you.all Objects you will ever create will be created with new %className%().
No, not at the moment. Built-in objects do not even have class objects, except for Object, Array and Map. Obviously, whatever you're trying to do with the class object is not going to work if there is no class object.There is no good way to get the class object of an object in AHK.
Code: Select all
;create COM object instance (for comparison):
oDict := ComObjCreate("Scripting.Dictionary")
;create object instance, 4 solutions (which can coexist):
oInstance := ObjNew("CustomClass")
oInstance := new "CustomClass"
;other names could be: Class (cf. Func), ClassGetDef, ObjGetClassDef
CustomClass := ObjGetClass("CustomClass") ;or a different function name
oInstance := new CustomClass
CustomClass := ObjGetClass("CustomClass") ;or a different function name
oInstance := CustomClass.New()
Code: Select all
Array := Class("Array") ;or equivalent
A_BIC.Array ;(built-in classes)
A_Class.Array ;for comparison, to help generate ideas
A_Classes.Array ;again, for comparison
Not that I understand what your point is, but this is a very useful feature, which have been greatly missed.jeeswg wrote: AHK v1 didn't have obj is ClassObject, and I never missed it. (I don't know if I've ever needed to check an object's class in any script, i.e. I created the object, so I know what class it has.)
@lexikos: Interesting. I feel that AHK v2 has already removed all of the quirky/unfortunate aspects of the AHK v1 syntax, but I think that A_XXX gives AHK some charm and character, and that's it's actually quite useful. Built-in variables minus the 'A_' would clutter the namespace, and replacing them with built-in functions would make code more verbose. Also 'A_' is significantly easier to type than '()' (which requires more of a wrist stretch and the use of a smaller finger for the ')'.)But then, the A_ prefix has always bothered me.