--!strict
-- Properties
type Properties = {
Instance: Folder,
Player: Player
}
-- Methods
type Methods = {
__index: Methods,
new: (instance: Folder) -> Facility,
claim: (self: Facility, Player: Player) -> (),
load: (self: Facility) -> (),
}
-- Type
export type Facility = typeof(setmetatable({} :: Properties, {} :: Methods))
-- Module Table
local Facility: Methods = {} :: Methods
Facility.__index = Facility
--[[ Creates a new facility-profile ]]
function Facility.new(instance): Facility
local self = setmetatable({}, Facility)::Facility
-- Properties
self.Instance = instance
-- Return Object
return self
end
--[[ Loads a specified facility ]]
function Facility:load()
self.Player = game.Players.Aensvey
end
-- Return Module
return Facility
My code was previously functional with older versions of the type checker. My main issue is that the new type checker no longer issues self a type even though it’s being cast within the Methods type (shown above). I’m able to work around this by re-asserting self within every function of the class, although I end up sacrificing conciseness & the benefits I get for using self in the first place.
The ‘work-around’ :
function Facility.load(self: Facility)
self.Player = game.Players.Aensvey
end
I’m aware shared self types are a planned feature, but in the meantime there seems to be no other way around this?
Using the luau type solver. Yes, the code will still do what it’s supposed to without it, but the entire point of enforcing strict type checking is to be able to write code more intuitively.
You could alternatively set up the class using the Facility table instead of a type alias.
--table
export type Facility = typeof(setmetatable({} :: Properties, Facility))
Then declare your methods inside the functions
--[[ Loads a specified facility ]]
function Facility.load(self: Facility)
self.Player = game.Players.Aensvey
end
function Facility.claim(self: Facility, Player: Player)
end
It won’t solve the original problem but it does let you avoid duplicating code.
The typing is not strict, you can pass whatever type you want regardless of what the solver thinks its should be. They are only annotations for your reading beneift. If you can reasonably figure out the type when reading then its just as good. I personally only use annotations on function signatures. In your case it should be self-evident that the type of self is Facility, because that’s whose method it is.
Like I said, yes it’ll still function, but I lose access to the autocomplete features in these extended methods & any type warnings I should receive unless I reiterate self’s type every time.