Class declaration conflicts with an existing class Topic is solved

[jNizM]

So if I import a class (whether from me or someone else) and I use the same "extends" class name, I can't use it and have to rename one class or the other?

Code: Select all

MsgBox a._func()
MsgBox b._func()

; class a =======================================

class a
{
	static _func()
	{
		return c._var
	}
}

class c extends a
{
	static _var := "c extends a"
}

; class b =======================================

class b
{
	static _func()
	{
		return c._var
	}
}

class c extends b
{
	static _var := "c extends b"
}

; ===============================================

[TheArkive]

class c extends a and class c extends b are duplicate class names in the same scope. If you nest those as a sub class then you can do it.

[jNizM]

I hoped the extends class would be enough to tell ahk that it is not a duplicate.

Sure, I could build everything under one class (nested), but that would get pretty huge for certain projects.

[TheArkive]

Here is one version of it that works:

Code: Select all

MsgBox a._func()

; class a =======================================

class a extends a.c
{
	static _func()
	{
		return this._var
	}
	
	class c
	{
		static _var := "c extends a"
	}
}

EDIT: Unfortunately this doesn't work the other way around because there is no distinct relationship between a class and a subclass unless that relationship is defined by the coder.

[jNizM]

But would not be practicable for a few more extends

[TheArkive]

This can be done more fluidly with class instances / prototypes:

Code: Select all

test := a()

MsgBox test._func()


; class a =======================================

class a
{
    Static __New() { ; this happens on class init / script start
        this.Prototype := a.c.Prototype
    }
    
	_func()
	{
		return this._var
	}
	
	class c extends a
	{
		_var := "c extends a"
	}
}

[TheArkive]

@jNizM

Here's the static version:

Code: Select all

Msgbox "final: " a._func()

; class a =======================================

class a
{
    Static __New() { ; this runs on class init / script startup
        For prop, obj in this.OwnProps() ; recursively attach all "sub items" of sub-classes ; applies to Static items and sub-classes only
            If (Type(obj) = "class")
                For prop2, obj2 in obj.OwnProps()
                    If (prop2 != "Prototype")
                        this.%prop2% := obj2
    }
    
	Static _func()
	{
		return this._var
	}
	
	class c
	{
        Static _var := "c extends a"
    }
}

EDIT: What exactly is the use case of NEEDING to have multiple classes with the same name in the same scope?

[kczx3]

You say scope but all class definitions are contained in the same scope...

Ultimately, you need modules/namespaces or the ability to import code to a namespace of your choosing to avoid things like this. I'm not sure this is super high on the priority list for Lexikos.

[TheArkive]

That makes more sense. Thanks for the correction.

[lexikos]

Putting aside extends for a moment, there were two ways that class c could work when that class has already been defined:

1. Raise an error.
2. "Reopen" the class, allowing more members to be defined.

Some reasons to go with #2 include:

• Allow more freedom with how the code is organized.
• Allow built-in classes to be extended more easily.

Ruby names the concept "open classes".

I hoped the extends class would be enough to tell ahk that it is not a duplicate.

This is one scenario where a "duplicate class" error should always be raised: there is exactly one global name, but two conflicting definitions. The class cannot have two direct base classes (and if it could, it would probably be better to require that they all be specified at once).

I don't know how you were expecting to know which class c should refer to in any given part of the script. It is no different to defining two global functions with the same name.

[lexikos]

I'm not sure [module/namespace support] is super high on the priority list for Lexikos.

At the moment, I'm just focusing on a project that's taken my interest (which kczx3 already knows about).

I think module/namespace support is important, and must be done right. @Helgef went to significant effort to implement namespaces in 2019 and 2020, and I intend to thoroughly review his code and provide feedback. I spent a few hours reviewing it last year, but long before finishing, I realized I was dissatisfied with the foundation upon which Helgef's code was built: the previous implementation and syntax.

That's what motivated me to finally implement my ideas for variable references and name resolution. The implementation changes needed for this were made with eventual support for namespaces/modules in mind (although maybe only small parts were relevant).

Having functions and variables (and properties and methods) in separate namespaces inhibited functional programming, but Helgef's pull request gave me the idea that it also complicated present syntax and functions, and would complicate other potential advancements. The specific trigger was that #UseVar and #UseFunc were used to import different kinds of names into the current namespace.

Microsoft's newer APIs are part of the Windows Runtime, which heavily utilizes namespaces in a way that makes them a bit inconvenient. My current project (see the top of this post) has been reminding me how useful module support would be, and also has me thinking that the implementation should allow importing names from dynamically generated sources, such as code that produces classes from metadata.

Some significant parts of the current implementation make it difficult to implement a few of my ideas. Rather than continuing to find ways to coerce it into doing what I want (like I did with closures and some other features), I intend to prioritize making foundational changes that may facilitate module support, dynamic script loading, REPL, expressions as parameter default values, overloaded operators/conversion methods, abstract data types, structs, async, AutoHotkey as a library... and anything else, if only by making the code easier to work on.


So rather than saying that it is high or low on the list, I will say that module/namespace support is somewhere within a complex and confusing web of priorities.

[jNizM]

Thanks for the / your clarification

[kczx3]

Some significant parts of the current implementation make it difficult to implement a few of my ideas. Rather than continuing to find ways to coerce it into doing what I want (like I did with closures and some other features), I intend to prioritize making foundational changes that may facilitate module support, dynamic script loading, REPL, expressions as parameter default values, overloaded operators/conversion methods, abstract data types, structs, async, AutoHotkey as a library... and anything else, if only by making the code easier to work on.


So rather than saying that it is high or low on the list, I will say that module/namespace support is somewhere within a complex and confusing web of priorities.

... You've got some hefty goals!

[20170201225639]

I intend to prioritize making foundational changes that may facilitate module support, dynamic script loading, REPL, expressions as parameter default values, overloaded operators/conversion methods, abstract data types, structs, async, AutoHotkey as a library... and anything else, if only by making the code easier to work on.

[Helgef]

Hello all

I intend to thoroughly review his code and provide feedback.

While feedback is always appreciated, I think a thorough review of my code is probably a waste of time. I don't think it is suitable to work on it given the changes which came after it. I'm very unlikely to work on it myself. If I were to find the motivation to work on a module system again I'd start over from scratch. I should of course have discussed the design before starting the implementation, or at the very least had a clear idea about what I wanted. But then, chances are that you lose your motivation before you start codIng if you drag it out.

I'm happy if my efforts have at least woken an interest about the topic.

Keep up the good work, fellow ahkers!

[lexikos]

@Helgef
My intention was to provide feedback for your benefit (and ultimately everyone else's if you continue contributing), and maybe learn something myself in the process.

[Helgef]

That is of course very much appreciated, any feedback is valuable for all of us which are interested in this project .

Cheers.