Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey_L v1.0.90 and Roadmap


  • Please log in to reply
48 replies to this topic
majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

Do you mean because it allows one to access variables of another function? Only the variables of the top-most instance of the function are available, and only while it is running.

Yes, thats what I meant. So, its not possible then.
Posted Image

tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007
Hi guys...just to report that I tried testing again with RegExMatch and it still doesn't work for the tests I gave it. Tutorial 11 in the gdi+ lib does not work as follows:

BRAFiles := BRA_ListFiles(BRA, "", 1)

; Alternate = 0			List File names
; Alternate = 1			List File numbers
BRA_ListFiles(ByRef BRAFromMemIn, FolderName="", Recurse=0, Alternate=0)
{
	if !BRAFromMemIn
		return -1
	Loop, Parse, BRAFromMemIn, `n
	{
		StringSplit, Header, A_LoopField, |
		if (Header0 != 4 || Header2 != "BRA!")
			return -2
		break
	}

	if (FolderName = "")
		NameMatch := Recurse ? ".+?" : "[^\\]+?"
	else
	{
		FolderName .= (SubStr(FolderName, 0) = "\") ? "" : "\"
		StringReplace, RegExFolderName, FolderName, \, \\, All
		NameMatch := Recurse ? RegExFolderName ".+?" : RegExFolderName "[^\\]+?"
	}
	Pos := 1
	Loop
	{
		Pos := RegExMatch(BRAFromMemIn, "mi`n)^(\d+)\|(" NameMatch ")\|\d+\|\d+$", FileInfo, Pos+StrLen(FileInfo))
		if FileInfo
		{
			if Alternate
				AllFiles .= FileInfo1 "|"
			else
			{
				SplitPath, FileInfo2, OutFileName, OutDirectory
				
				if (OutDirectory = SubStr(FolderName, 1, StrLen(FolderName)-1))
					AllFiles .= OutFileName "|"
				else
					AllFiles .= SubStr(OutDirectory, InStr(OutDirectory, "\", 0)+1) "\" OutFileName "|"
			}
		}
		else
			break
	}
	StringTrimRight, AllFiles, AllFiles, 1
	return AllFiles
}

The regex takes a long time to complete and fails

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
BRA_ListFiles gives me the same results in AutoHotkey_L v1.0.90 as it does in AutoHotkey Basic: 1.jpg|2.jpg|...|1032.jpg|1033.jpg|1

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007
I see the points and benefits from prototype based things, but I think also it would be nice to have a bit syntax help if I want design an class.

I personally prefer dynamic languages over those that follow strict protocols because you can "reconfigure" particular "instance" of an object on the fly.

Don't understand me wrong - if I want a full blown, strict design, I use a language which was designed for this purpose. Majk, I'm also with you in the point on flexibility, but the ability to define "objects" expecally if we talk of not very abstract ones, its IMHO much easyer to understand and read code which is splited up in classes.

Im not against the abilities of AHK_L - but it should not limited to that.

Lets say, something like PHP - a low typed OOP language, plus dynamic support of Declaration - the prototyping.

I think PHP shows best how it's possible to mix typed classes with not typed structured code. And I can understand Lexikos - its not made when Mr IsNull says "I wan't class support " - first we have to figure out how to fit this into a not typed language :)

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
What are the practical benefits of your proposal over simply commenting and structuring the code? What are the benefits in general?
; ==== class Dll ====
;
    Dll(path) {
        return {Path: path}
    }
    Dll.Register(this) {
        run, % "regsvr32 /s""" this.Path """"
    }
    Dll.FileName(this) {
        fullPath := this.Path
        SplitPath, fullPath, fileName
        return fileName
    }
;
; ===================

Im not against the abilities of AHK_L - but it should not limited to that.

Implementing "class foo {}" syntax will not expand any limits except maybe those that are self-imposed.

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007
The class block must have some benefits, which a) spare typing and B) give some better readable code:

class Car
{
	Name := "default"
	Color := new Brush("Red")
	doorOpen := false
	
	OpenDoor(){
		this.doorOpen := true
		MsgBox % "Heya, you just opened " this.Name "'s doors."  
	}
}

;vs:

Car := Object()
{
	Car.Name := "default"
	Car.Color :=  Brush("Red")
	Car.doorOpen := false
	
	Car.OpenDoor := "Car_OpenDoor"
	
	Car_OpenDoor(this){
		this.doorOpen := true
		MsgBox % "Heya, you just opened " this.Name "'s doors."  
	}
	
	Car(){
		global 	Car
		return Object("base", Car)
	}
}

Also, in hard defined way like above, it should be possible declaring Fields as private, and throw exceptions if they accessed external... but this is a lot of more work - but the easy class syntax should be reachable :)

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Rather than comparing to what we have now, compare to what I've put on the roadmap:
; ==== class Car ====
Car() {
    global Car
    return { Name: "default"
        , Color: Brush("red")
        , doorOpen: false
        , base: Car }
}
Car.OpenDoor(this) {
    this.doorOpen := true
    MsgBox % "Heya, you just opened " this.Name "'s doors."  
}
; ===================
I think the small amount of extra typing (repeating the class name) would be worth the added clarity, especially with larger classes, where you would need to scroll around to determine which class you're looking at. It's still much less verbose than C++. A couple of improvements may be possible: super-globals (avoiding the need to declare specific global variables in each function) and more intelligent continuation:
return {
         Name:     "default",
         Color:    Brush("red"),
         doorOpen: false,
         base:     Car
       }

Name := "default"
Color := new Brush("Red")
doorOpen := false

That would take time to implement (since it can't be parsed as a regular assignment) and the end result would be inconsistent with the code inside the object's methods, which must necessarily use the "this." prefix.

it should be possible declaring Fields as private, and throw exceptions if they accessed external...

There are far more important areas that do not "throw exceptions", such as certain syntax errors in expressions, failed dynamic function calls, math with non-numeric values, etc. Access control features do not belong in AutoHotkey. Furthermore, the current design does not allow it.


Every time- or keystroke-saving feature has a cost; specifically, my time and energy. Therefore, if there isn't some other strong reason to implement it, I probably won't. The Type.Method(){} approach might be slightly incompatible with methods-in-functions as proposed by jethrow. I will consider whether this constitutes a "strong reason"...

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

I think the small amount of extra typing (repeating the class name) would be worth the added clarity

In Ruby , this is the only way to define class methods (vs instance methods). Even tho you are inside the class body you need to specify full class name prior to method.

It should be possible declaring Fields as private, and throw exceptions if they accessed external...

Altho this is not possible and pretty much needed for encapsulation, its not that hard to design class that will take care of this manually. After that, all other classes that need that behavior could use it as a base.

Every time- or keystroke-saving feature has a cost; specifically, my time and energy.

This is very important now as we don't have other active developers. Lets help Lexikos by determining what is really needed and what really makes a difference.
Posted Image

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Having class syntax would allow to use the objects without actually running the part of the code where the base object is defined. This way it would be possible to use classes by simply including a (library) file.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Altho this is not possible and pretty much needed for encapsulation,

I'd say it is encapsulation, or one form of it, but still unnecessary and not appropriate for AutoHotkey. If for some reason you see a need to keep data private, you can use assume-static or store internal data in a separate object in a static variable.

Having class syntax would allow to use the objects without actually running the part of the code where the base object is defined.

So would Type.Method(params) { … } as defined on the roadmap.

tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007
objects in ahk scare me. the syntax seems so foreign to me. i would have preferred something like:

Fred := Obj("Person")
Fred.Weight := 185
Fred.Walk(10)
return

Person
{
	Weight
	Height
	Walk(Distance)
	{
	}
}

i appreciate that you are taking a large project on, but at a glance it seems very confusing to me...i write all of my programs in c# so havent tried AHK_Ls features out yet

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

the syntax seems so foreign to me.

What syntax? The "syntax" for creating an object? That's standard AutoHotkey function syntax...

Some elements of your example are too ambiguous; for the parser and human readbility both.

pekkle
  • Members
  • 13 posts
  • Last active: Nov 07 2013 04:27 AM
  • Joined: 20 Jan 2009
ahk2exe not support /NoDecompile anymore ? :twisted:

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

If you plan to distribute your EXE and don't want anyone to be able to view the source code of your script, consider using a non-standard executable packer. MPRESS, which AutoHotkey_L uses by default, may provide sufficient protection for most users. Password protection is supported only for 32-bit compilations and the /NoDecompile switch is no longer supported at all.
Source: AutoHotkey_L Documentation

Note that the latest version of the installer does not include mpress.exe, as there were reports of virus false positives. It can be downloaded from the MPRESS website.

AutoHotkey_L is based on source code originally downloaded from the AutoHotkey website, which did not contain an implementation for /NoDecompile. The same goes for Ahk2Exe_L; both the original Ahk2Exe.exe and original AutoHotkeySC.bin are required for /NoDecompile to work. My understanding is that /NoDecompile adds an extra layer of encryption which would be easily defeated if the source code was released.

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007

/NoDecompile

Dosn't do anything usable other than prepend non existent security.

My understanding is that /NoDecompile adds an extra layer of encryption which would be easily defeated if the source code was released.

It is alread defeated. Its just about the censorship in this forum why not too much of the people here know about.