Feature Request: Abstract classes and protected visibility

[tullisar]

First off, as an embedded C/C++ dev who has only just been getting into Lua for fun, this library has been a blessing! I've mostly been using it for my own library addon to provide enhancements and reusable code for other addons like WeakAuras and such. However, I was drafting a design to take advantage of Interfaces, but also realized that there are a few things I couldn't do with it. I wanted to create an abstract base class that implemented an interface to provide things like common base constructor. Below is an example of what I have now (sorry for the wall of code!)

Current Code

-- Assumes package is already defined.
local IFoo = package:CreateInterface("IFoo", {
  GetText   = {type = "function", returns = "string"},
  GetNumber = {type = "function", returns = "number"}
  Print     = {type = "function" }
}

--[[
Intended to be an interface "default" function. Maybe I did something wrong,
but I was unable to do something like:
function IFoo:Print(data) print(self:GetText() .. self:GetNumber()) end
--]]
function IFoo.Print(obj)
   print(obj:GetText() .. obj:GetNumber())
end

-- "abstract" base class and constructor definition
local CAbstractFoo = package:CreateClass("CAbstractFoo", nil, IFoo)
package:DefineParams("number")
function CAbstractFoo:__Construct(data, number)
  data.number = number
  self:CheckNotAbstract()
end

-- A function used to somewhat enforce the abstract nature of the class.
package:DefineVirtual()
function CAbstractFoo:CheckNotAbstract()
  error("This class is abstract and should not be instantiated!")
end

-- Base implementation to return common state
package:DefineReturns("number")
function CAbstractFoo:GetNumber(data)
  return data.number
end

-- "abstract" method that I would have left out in the base class were it
-- possible
package:DefineVirtual()
package:DefineReturns("string")
function CAbstractFoo:GetText()
  error("This function is abstract, and should not be called!")
end

-- Print implementation using the interface default method.
function CAbstractFoo:Print()
  IFoo.Print(self)
end

-- Concrete class and constructor definition
local CConcreteFoo = package:CreateClass("CConcreteFoo", CAbstractFoo)
package:DefineParams("string", "number")
function CConcreteFoo:__Construct(data, text, number)
  self:Super(number)
  data.number = number
end

-- Implementation to shadow base class to avoid "abstract" error.
function CConcreteFoo:CheckNotAbstract()
  -- Do nothing dummy function
end

-- Implementation to shadow base class to avoid "abstract" error.
package:DefineReturns("string")
function CConcreteFoo:GetText(data)
  return data.text
end

There ends up being a lot of boilerplate code for things that could be implemented as interface default methods. If the library supported it, maybe the code in my example would look something like this?

Code with Suggested Features

-- Assumes package is already defined.
local IFoo = package:CreateInterface("IFoo", {
  GetText   = {type = "function", returns = "string"},
  GetNumber = {type = "function", returns = "number"}
  Print     = {type = "function" }
}

--[[
Something like this could be used to define an interface method that doesn't
know about any object state other than that defined by the interface itself.
--]]
package:DefineDefault()
function IFoo:Print()
   print(self:GetText() .. self:GetNumber())

   --[[
   Behavior like these should result in an error however. When the scope of
   self is the interface, giving access to methods from child classes
   amounts to reflection. Also, allowing direct modification of an object's
   properties that aren't exposed by the interface's definition would be
   asking for coupling issues galore in client code down the road.
   I've seen some gross things done in C++ with stateful pure virtual
   classes and it makes me wince 😅.

   if self:GetName then print(self:GetName()) end
   self.sideEffect = true

   --]]
end

--[[
Something like this could be used to mark a class as abstract, and if that
class implements any interfaces, the framework would not treat missing
interface functions as errors. Called right before the creation of the class,
it would accept a table of abstract function definitions that must also be
implemented by non-abstract children in addition to any unimplemented
interfaces.
--]]
package:DefineAbstract({
  GetName = {returns = "string"}
  DoubleNumberAndAdd = {params = "number", returns ="number" }
}

--[[
Something like this could be used to ensure that only classes in the same
package can declare the protected class as a parent. For example, calling
CreateClass("CConcreteFoo2", CAbstractFoo) from a different package would
result in an error from the framework.
--]]
package:DefinePackageVisibility()

--[[
Create the abstract class, and no abstract instantiation check is required
by client code. Attempting to call CAbstractFoo(0) would result in an error
from the framework.
--]]
local CAbstractFoo = package:CreateClass("CAbstractFoo", nil, IFoo)
package:DefineParams("number")
function CAbstractFoo:__Construct(data, number)
  data.number = number
end

--[[
Something like this could be allowed to provide a default implementation for
DoubleNumberAndAdd, but still require that children implement it. Children may
call it explicitly like any other parent method however.
--]]
function CAbstractFoo:DoubleNumberAndAdd(number)
  return (self:GetNumber() * 2) + number
end

--[[
Something like this would be used to override the default implementation of
the interface, giving more visibility into the object's state. I've used
self.Interfaces as an example of how it might be accessed (similar to calling)
parent methods.
--]]
function CAbstractFoo:Print(data)
  self.Interfaces:Print()
  print(self:GetName())
end

-- Base implementation to return common state
package:DefineReturns("number")
function CAbstractFoo:GetNumber(data)
  return data.number
end

--[[
Something like this could be the mechanism for defining protected functions.
Just like functions defined on the Private table, they would not be visible
outside the scope of the current class, with the exception that child classes
would be able to call them using data:Call(). These methods could also be
allowed to have package:DefinesVirtual() to allow a child to override the
method.
--]]
package:DefineReturns("number")
function CAbstractFoo.Protected:GetHalfNumber()
  return self:GetNumber() / 2
end

-- Concrete class definition
local CConcreteFoo = package:CreateClass("CConcreteFoo", CAbstractFoo)
local fooInstance = CFooConcrete("test", 0)

-- Concrete class constructor
package:DefineParams("string", "number")
function CConcreteFoo:__Construct(data, text, number)
  self:Super(number)
  data.text = text
end

-- GetText required implementation from interface
function CConcreteFoo:GetText(data)
  return data.text
end

-- GetName required implementation from abstract class
function CConcreteFoo:GetName(data)
  return "childUsingProtected:" .. data:Call("GetHalfNumber")
end

I'm still getting the hang of Lua in general, so hopefully things make sense!

[Mayron]

Thanks @tullisar for the feature request and I like the idea and package:DefineDefault() seems like a reasonable way of defining a default method. I have been working hard on refactoring the code so there will be some future changes and I would be very happy to add this in for you before the next big update.

The interface support was originally designed to add an extra layer of security to enforce more complex strict typing rules, and so it currently does not work in the way you want it to. This would be difficult to implement with the current version of MayronObjects. However, with the new version I am working on, this feature should be much simpler to implement.

Thanks for the "wall of code" as that helps me understand how you intend to use it 👍

[Mayron]

@tullisar I have added default interface methods. What do you think of this?

Example

  -- this is a default interface method:
  local function Execute(self, data, value)
    self:Print("Execute:", data.message, value);
    return "success";
  end

  local IDummyInterface = obj:CreateInterface("IDummyInterface", {
    Execute = {
      type = "function";
      params = {"number"};
      returns = {"string"};
      default = Execute;
    };
  });

  local DummyClass = obj:CreateClass("DummyClass"):Implements(IDummyInterface);

  -- alternatively, you can type:
  -- local DummyClass = obj:CreateClass("DummyClass");
  -- DummyClass:Implements(IDummyInterface); -- or the name of the interface "IDummyInterface"

  function DummyClass:__Construct(data)
    data.message = "testing";
  end

  function DummyClass:Print(_, arg1, arg2, arg3)
    assert(arg1 == "Execute:");
    assert(arg2 == "testing");
    assert(arg3 == 123);
  end

  local instance = DummyClass();
  local success = instance:Execute(123);
  assert(success == "success"); -- this passes

You may have noticed the new "Implements" function to say that a class implements 1 or more interfaces. I took this out of the CreateClass function as this function now accepts multiple parent classes (using Blizzard's Mixin system). You can ignore this for now as I will explain all the changes to the newer version of the framework I'm releasing this month.

The interface "definition" table will also accept the same rules as the DefineParams and DefineReturns arguments. I'm trying to standardize these strict typing rules, so in future you will need specify the type and default values for complex types using:

obj:DefineParams({ type = "function", default = myFunction });

Instead of the current method:

obj:DefineParams({ "function", myFunction });

This makes things more explicit but also allows the framework to use the same code it uses for interfaces and makes the whole process easier..

[tullisar]

I think it looks great, I like how the new implements feature works. Creating a class this way gives Builder pattern vibes, which I'm a huge fan of. However, the default function that also accepts self and data parameters can really run the risk of unintended data coupling.

Taking the example you've shown, IDummyInterface really has no business being able to call self:Print since it wasn't also defined in the interface itself. IDummyInterface is now coupled to DummyClass in a way that the public API of the interface doesn't imply.

If possible, I think it would be good if default functions defined when calling obj:CreateInterface didn't accept the data parameter, and the self parameter that was passed to it is perhaps a proxy that only exposes the functions and properties known to the interface itself. Additionally, it would be helpful for the framework to throw an error when trying to call functions other than those expected by the interface on self

I'm back at work this week so I may not have as much Lua time on my hands but I'll try to stay on top of any other discussion :)

[Mayron]

@tullisar You raise a good point. The old version of MayronObjects did this but the newer version uses Blizzard Mixins because they are better on performance. The only problem with this approach is that you lose the ability to control the hierarchy of parent relationships. I may revert back to the original method if I can find a happy medium for performance. I don't want too much overhead as this can cause reduced FPS when playing in World of Warcraft when you need to access the same method multiple times, such as in an OnUpdate script.

Currently, to improve on the performance I created a "snapshot" of the hierarchy and added each function onto the instance. This seems to improve performance. However, this means that changing a parent class method would not automatically be updated and applied to the instance and you can't tell the instance that "this method came from X" to let it know what properties and methods it has access to. In the older approach, I had more control over it but it involves a lot more processing instead of just instantly calling the function you expect it to call.

I had a think about this and I'm sure I can find a happy medium between the two approaches, so I can give this a go. I'm not 100% sure about the private instance data not being injected in. Sometimes I wonder if simulating exactly what a high-level OOP language is the right move for a Lua based one for WoW as I don't know if that would be useful or not. Interfaces were simply a method of applying more strict-typing rules to guarantee that you had a property or method on the object if it was of that type of interface. I'll give this a go, as I might as well make it work as expected 👍

So default interface methods should have no private instance data, but what about parent class methods? I suppose they need their own private instance data for a given instance for that class only? Or, would renaming this concept to "protected instance data" be better? So this table is shared between all classes in the hierarchy except for interfaces. I personally think this is more useful, else I wouldn't want to use parent classes as much as I do now. I can't think of a good way of including both private and protected instance data. One argument injected into each method is enough I think.

Sorry for the wall of text. I was debating the idea in my head and it all came out lol

[tullisar]

I don't want too much overhead as this can cause reduced FPS when playing in World of Warcraft when you need to access the same method multiple times, such as in an OnUpdate script.

In general, just like tables, I think folks should be discouraged from creating and destroying objects in OnUpdate scripts, especially not via their constructors. In a function that's called as often as OnUpdate might, I'd really suggest client code that makes use of a factory method pattern. That pattern allows the client code to make the decision to use its own pool/arena of memory, or something like framework:PopTable(...).

The only problem with this approach is that you lose the ability to control the hierarchy of parent relationships.
...
Currently, to improve on the performance I created a "snapshot" of the hierarchy and added each function onto the instance. This seems to improve performance.

I took a quick look at Mixins, and I'm not quite sure I understand the naming they chose. The Mixin function seems to basically just be a collector that merges a bunch of tables together in order. The various *Mixin pool API seems to be related to Mixins in that they use them to create a hierarchy of pool types.

I think taking advantage of Mixins is a good design. Interface and class definitions should be immutable (like in a compiled language). They should also be created once (when the addon is loaded) and live until the addon is unloaded. A good way to implement the creation of classes (and to enhance the learnability of the framework) would be to explicitly use the builder pattern for the creation of interfaces and classes. Something like local CFoo = package:DefineClass("CChild"):Extends(CParent):Implements(IFoo, IBar):Build() (or with some kind of table schema). The framework can assemble things from the builder to create the immutable class definition, then when constructing objects of that type can use Mixin(...) as needed. I'm also of the belief that not enough objects themselves are immutable in codebases out there. I've had enough headaches for things that should be immutable, but aren't really, to last a lifetime 😅 . I think some clever metamethod use could make things immutable where needed.

Sometimes I wonder if simulating exactly what a high-level OOP language is the right move for a Lua based one for WoW as I don't know if that would be useful or not. Interfaces were simply a method of applying more strict-typing rules to guarantee that you had a property or method on the object if it was of that type of interface. I'll give this a go, as I might as well make it work as expected 👍

It's a valid question to ask if OOP is right for WoW Lua. Sometimes the advantage of Lua in WoW is the near global mutability of objects, I'll bet that helped make the modding community so vibrant an active. Even as I look at this I sometimes ask myself if I've spent too much time overthinking all of this ha. I do actually think there's an audience for it though (those of us who come from a background that gets to use it regularly for work for example). I think also focusing on making the framework performant while also increasing its usability can help it grow though. Really understanding design patterns and OOP doesn't come easily to everyone, so a framework that can guide by example is useful even for new coders.

So default interface methods should have no private instance data, but what about parent class methods? I suppose they need their own private instance data for a given instance for that class only? Or, would renaming this concept to "protected instance data" be better? So this table is shared between all classes in the hierarchy except for interfaces. I personally think this is more useful, else I wouldn't want to use parent classes as much as I do now. I can't think of a good way of including both private and protected instance data. One argument injected into each method is enough I think.

I think working toward a visibility pattern that is consistent with compiled language, using the same "Public/Private/Protected" rules would really help. It seems like it might be possible to use a combination of the immutable class definition and some crafty metatables to make this work.

Sorry for the wall of text. I was debating the idea in my head and it all came out lol

I get ya! Sometimes just writing it all out is the best way to make sense of things. I'm happy to offer any input I can 😄 . If you have a branch you're willing to share I'd be happy to take a look when I have some time later in the week!

[Mayron]

In general, just like tables, I think folks should be discouraged from creating and destroying objects in OnUpdate scripts.

This would be terrible indeed, but when I talk about overhead I'm referring to complex __index and __newindex metamethods causing the misconception that their OnUpdate script is small but really MayronObjects is doing a lot of work behind the scenes before even calling the object's method. This is why the Mixins approach calls the real function directly without needing to look up the function in a hierarchical inheritance tree like the current model does. Maybe there is a more effective method that combines the best practices from both methods. I definitely want to explore this and this conversation has really helped.

Interface and class definitions should be immutable (like in a compiled language). They should also be created once (when the addon is loaded) and live until the addon is unloaded.

Absolutely. That's my original design intent with the framework. However, sometimes I've noticed that instances are created before all class methods have been defined and this seems like an annoying detail to remember when using the framework, so snapshots aren't always good. To solve this in the newer design using Mixins, I treated methods like a cache after the snapshot. So if a method did not exist then it would take it from the closest parent class. Still, this approach doesn't let you create that level of isolation between parent classes like you briefly touched on.

I worry about immutability in WoW Lua because the nature of immutable objects and methods that return new objects implies a lot of wasted tables and memory usage. Yes, I could use PopTable and PushTable to clean up old tables, but what if a user holds onto a table somewhere in their own code and suddenly the recycling job clears out the contents of that table and thinks it's been deleted? I've seen this problem quite often and it causes difficult bugs. You would need to ensure that only the framework knows about these tables and it would be difficult to implement. I'm not sure if the WoW Lua environment needs this honestly. Thanks for the suggestion though as nothing is final and I'm open to it but only if it's done in a practical manner.

Sometimes the advantage of Lua in WoW is the near global mutability of objects

This enforces my previous point. I'd agree with this simply because memory leaks are a hassle to fix and I've spent a long time writing unit tests to check that memory usage remains low when making this framework.

It seems like it might be possible to use a combination of the immutable class definition and some crafty metatables to make this work.

I use the data argument because it's the most natural way in Lua to make something truly private, because you cannot bypass a metatable to grab the private data as it's stored in the framework. It feels very unique to the framework and I like that. It also looks much nicer and feels more elegant to do data.message = "hello", instead of self.private.message = "hello", but that's just me. It is also not possible to hide private and protected keys on the self object reference when outside the scope of the object's method. It cannot be done because you could pass self to other functions inside that same method scope and you would have zero control over this.

Here's a potential solution: You could write data._message and the framework interprets _ as being private, and data.message as protected data. Because honestly, I think I'd use protected data usually always unless I used inheritance which seems not as common in WoW Lua. I've only used inheritance a couple of times. Most of my classes are just standalone classes, like C_ActionBar for controlling an action bar. Classes representing elements in the game rarely need inheritance but there are certainly many use-cases for them.

If you have a branch you're willing to share I'd be happy to take a look when I have some time later in the week!

Thanks! I'll most likely be rewriting a lot after our discussion here so I'll let you know when :)

[Mayron]

Just to add to my point on not being able to control what's on the `self` referential variable:

local function SomeFunction(testClass)
  -- what does testClass contain as public properties?
  -- should the same instance have different properties - would this be confusing and error-prone?
  obj:PrintTable(testClass);

  -- for example, when passed this object from `ExecuteFromParent`, the following
  -- would fail because we took "CallChildMethod" away to mimic a ParentClass instance object:
  testClass:CallChildMethod();
end

local C_TestClass = obj:CreateClass("ParentClass")
local C_ParentClass = obj:CreateClass("TestClass"):Extends(C_ParentClass);

function C_ParentClass:ExecuteFromParent()
  SomeFunction(self);
end

function C_TestClass:Execute()
  SomeFunction(self);
end

function C_TestClass:CallChildMethod()
  print("testing...");
end

local testClass = C_TestClass();
testClass:Execute();
testClass:ExecuteFromParent();

I remember you saying that it would be good to control what's on self when used inside an interface but this tends to lead to confusion. I'm not sure what to do in situations like this, which is why I tend to let the programmer rely on their design choices for what they access from the parent or interface methods. It's simply a bad design to do what I added in the previous code example when I accessed parent class methods from the interface. That code example was only taken from a unit test because that situation needed to be tested, but in practice, I would not try this. Lua does not have the ability to know when you leave a method/function scope so it's difficult to add this particular OOP feature into Lua.

Even worse, if you try to add asynchronous code into the equation when using C_Timer API, you would need the overhead of "proxy" self objects, which I would rather avoid. This is partly why I think this level of trying to mimic true OOP in WoW Lua might be too much.

EDIT: After thinking about this, maybe this could work as long as the programmer knows and accounts for this. We could add casting to downcast or upcast an instance object as well. It could either throw an error or return nil is the cast cannot be done:

Casting Example

-- supplying the namespace:
local parentClass = obj:Cast(testClass, "ParentClass");
local childClass = obj:Cast(parentClass , "ChildClass");

-- supplying the class itself:
local parentClass = obj:Cast(testClass, C_ParentClass);
local childClass = obj:Cast(parentClass , C_ChildClass);

[tullisar]

I agree, especially with inheritance - I think it can be used wrong so easily. It's hard to even make a good use case for a big 'ol inheritance tree in a WoW addon. I'm even walking it back on my design, after stopping and realizing yet again, composition would be better 😅 . Sometimes without co-workers to chat design with I fall back on old habits ha. And you're right, sometimes we just need to let the programmer make their own good design choices. If they make bad ones and it bites them later down the road then it'll just be a learning experience.

I probably won't have as much time to dedicate to this until the weekend now that I'm back at work after the holidays. I'll try to think a bit more on what might actually be valuable beyond the interface default methods :)

[Mayron]

I probably won't have as much time to dedicate to this until the weekend now that I'm back at work after the holidays.

No problem. I really appreciate the help. I'm still debating ideas. I like the idea of protected visibility but I don't want to increase the overhead so I'm trying to experiment to see what's the most efficient method for this. However, another large concern is what the "syntax" would look like because Lua lacks linting support for these features being discussed and so adding too much magic into a framework can leave other developers confused (i.e. those who are unfamiliar with traditional OOP).

The current version does not enforce these rules because it follows the "pythonic" way of doing things by leaving it up to the developer to trust each other, which is closely related to how Lua handles things. In python, you write self.__value to tell other programmers to "please don't touch as it's supposed to be private".

I don't know if I like the idea of specifying every property in a class definition table (but that would be consistent with how interfaces currently work). Maybe every "field" (protected and private properties) could be private by default and then if you want something to be protected you should specify it. Also, specifying rules for fields and properties should always be optional in my opinion. I came to this conclusion because if fields were protected by default and you attempt to reassign a protected field from a sub-class when it was originally specified from a parent class, then the logic gets confusing; should the sub-class create a new "shadowed" field that overrides it, or should some meta-table magic assign the value at the parent level? If you have things private by default then it solves this confusion.

EDIT: You can ignore the following and skip to my last comment where I mentioned why I won't be doing this for now.

---

This idea is a little out of the box compared to how the framework currently works so you might not like this. Below is an illustration of all possible theoretical options when creating a new class:

Creating Class Definitions

local CTestClass = obj:CreateClass("TestClass", {
  Extends = CParentClass;
  Implements = { IFoo, IBar };
  GenericTypes = { "T1", "T2" }; -- treat these as placeholders to be used for instances using the class as a generic class.
  Abstract = false; -- (default is false) prevents instances from being instantiated from this class.
  Final = true; -- an option to prevent other classes extending it (similar to sealed in c#)
  Locked = true; -- prevents new methods (public, private or protected) from being added or changed
  Properties = {
    Public = {
      myProp = "number";
      MyFunc = {
        type = "function";
        params = {"number", "string"};
        returns = "SomeClass"
      };
    };
    Protected = {
      id = "number=123";
      Execute = {
        type = "function";
        params = "table";
      };
    };
    Private = {
      _message = "?!string"; -- "?!" = can be nil until assigned a value
      _values = "?table"; -- can always assign nil to it
      MyPrivateFunc = {
        type = "function";
        returns = { "boolean", "?table" };
      };
    };
    Static = {
      Refresh = "function";
    }
  };
});

I could also have an alternative approach depending on the programmer's preference. This is a builder pattern version of the above. I personally like the configurable definition table approach but it's less user-friendly. With the builder approach you could use linting (or with the EmmyLua vscode extension) to discover what functions you can use:

Creating Class Definitions with Builder Pattern

local CTestClass = obj:DefineClass("TestClass")
  :Extends(CParent)
  :Implements(IFoo, IBar)
  :MarkAsAbstract()
  :MarkAsFinal()
  :Lock()
  :WithGenericParams("T1", "T2")
  :WithProperties({
    -- example properties omitted for brevity
    Public = { ... };
    Protected = { ... };
    Private = { ... };
    Static = { ... };
  })
  :CreateClass();

At least with this technique, all the rules are contained in one place. However, you should still be able to add method definitions inline with its implementation (but not be allowed to override ones included in the definition table). Sometimes it might be easier to use the definition table, though, especially for abstract and interface methods.

obj:DefineParams("boolean");
function CTestClass:Execute(data, value) end

[Mayron]

@tullisar After drafting up several designs, adding protected visibility seems to be a huge challenge for Lua, mainly for public and protected properties. I might be able to add a way for private properties to be private for a given hierarchy level but for properties that need to grow in scope the further down the hierarchy you go, this would be a challenge. Scoped protected visibility such as this would involve far too much overhead for it to be practical. Lua also makes it very difficult to enforce this for multiple situations, such as when using asynchronous code as this would require cloning the instance for each node in the hierarchical tree. You cannot cast an instance to a parent class version of that instance in case some asynchronous code is using that same instance object and depends on other versions of that instance.

I can add abstract classes, and default interface methods in the style that you suggested - by adding them directly to the interface object returned by CreateInterface - as this should not be difficult. Also, your package visibility idea to protect classes being used as parents for classes outside of the package they're defined in should be simple to add. I will leave the previous "out of the box" concepts I included in my previous comment. I'm glad we talked about this because it has allowed me to understand the nature of Lua and the areas that cannot be achieved with a Lua-based OOP framework compared to a full-OOP language, such as Java and C#. Lua is more closely related to python than full-OOP based languages, and I think it makes more sense to follow the pythonic philosophies even though I agree with how this can lead to bad programming styles, such as in the example you gave in your original comment on default interface method misuse.

The main difference between this framework and full-OOP is that the data table is shared between all levels of the hierarchy and should be thought of as a big bag of protected instance properties. I think we should let the programmer use this wisely based on their own understanding of OOP. I can omit this data table for interface methods, though. It's the same with the self reference - I cannot intelligently swap out public properties from this object for the same reason - the overhead is too great, it leads to complex bugs because Lua simply doesn't know how to deal with this, and you would need complex definition tables like I previously posted in order to solve confusing logic.

Maybe I can return to protected visibility after adding abstract classes and interface defaults :)

[tullisar]

I think that sounds great. Just getting back to this now. I thought about it a bit throughout the week myself and kind of came to the same conclusion. Everything I could think of felt messy and or like it might suffer performance-wise. Definitely something to think about though! It's definitely important to be critical of the features you add to a library like this too. I definitely haven't been working with Lua for very long so I'm still what is and isn't possible in the language ha.

Are you still looking at using a builder pattern for classes/interfaces or something similar to the way it is now with package:DefineParams and such?

[Mayron]

@tullisar I think I found a way to effectively add protected visibility in a way that isn't confusing. Still experimenting with this but I'm no longer ruling it out.

Basically, if I create a new instance for each "node" in the hierarchy tree and link them together then it can be done. If you have a very complex hierarchy then that's a lot of extra data. However, in WoW I doubt you would need so many sub-classes from my experience so I doubt this will be too problematic. When you destroy the instance it will destroy all of these instances that are linked together and you can use IsType to figure out if an instance is connected to any of the types in this linked collection of instances. I've also added a Cast framework method to cast an object down to a sub-class version of that instance for rare situations when this is required - but I never like casting and I would recommend avoiding this.

I didn't want to have to specify each property for protected visibility to work and to keep the design of the framework simple for the user, as that was my main concern in addition to the overhead. I made it so that you can only specify the type of public properties but you can always use the framework's IsType helper method if you want to manually check other values such as private and protected properties.

Are you still looking at using a builder pattern for classes/interfaces or something similar to the way it is now with package:DefineParams and such?

I think the builder pattern is a bit messy. It's good if you have a complex class but for most use-cases it would seem overkill. I would rather keep using the package's DefineParams and DefineReturns at the top of methods but keep interface definition tables working the same way as it works now for interfaces but to also let abstract classes and normal classes use these definition tables too. You can either use DefineParams and DefineReturns or specify these definitions inside the definition tables. The only difference is that you would need to use the definition table if there is no implementation of that method available (for abstract and interfaces). For example:

--1st param = the class name
-- 2nd param = the parent class
-- 3rd param = a table containing interfaces to implement (abstract classes do not have to implement these)
-- 4th param = a definition table similar to how interfaces work

local AbstractClass = package:CreateAbstractClass("AbstractClass", nil, nil, nil, {
  MyMethod = { -- an abstract method with no implementation
    type = "function";
    params = { "number", "?string" };
    returns = "boolean"
  };
});

-- Or, if `MyAbstractMethod` actually had an implementation then you could also use:
local AbstractClass = package:CreateAbstractClass("AbstractClass");

package:DefineParams("number", "?string");
package:DefineReturns("boolean");
function AbstractClass:MyMethod(data, a, b)
  return true;
end

However, you can't use both of these styles of defining a method because then you would get an error saying you can't redefine the same method.

This would allow for normal classes to use this feature to define public properties and I think the design is very consistent:

local Class = package:CreateClass("Class", nil, nil, {
   MyPublicProperty = "string";
});

function Class:__Construct()
  self.MyPublicProperty = "foobar"; -- can only be assigned a string
end

local instance = Class();
print(instance.MyPublicProperty); 

[tullisar]

Right on! I think this sounds great. I'm looking forward to seeing how it turns out! :)