Interface

[ocots]

We can have function on abstract struct that use the field but we must add a test and throw an error if the field does not exist.

CTModels.jl/src/nlp/options_schema.jl

Lines 100 to 111 in ac5a9f3

	function _options_values(tool::AbstractOCPTool)
	return tool.options_values
	end
	"""
	$(TYPEDSIGNATURES)
	Return the option sources (`:ct_default` or `:user`) for a tool instance.
	"""
	function _option_sources(tool::AbstractOCPTool)
	return tool.options_sources
	end

[ocots]

Clarify the interface for an AbstractOCPTool.

[ocots]

Here we use a getter and not a field from the struct. We need to clarify the interface.

CTModels.jl/src/nlp/options_schema.jl

Lines 3 to 25 in ac5a9f3

	"""
	$(TYPEDSIGNATURES)
	Return a short `Symbol` identifying the package or implementation used by a
	given [`AbstractOCPTool`](@ref).
	Concrete tool types are expected to specialize this method on their own type,
	for example `get_symbol(::Type{<:MyTool}) = :mytool`.
	"""
	function get_symbol(tool::AbstractOCPTool)
	return get_symbol(typeof(tool))
	end
	"""
	$(TYPEDSIGNATURES)
	Default implementation that throws `CTBase.NotImplemented`.
	Concrete tool types must specialize this method.
	"""
	function get_symbol(::Type{T}) where {T<:AbstractOCPTool}
	throw(CTBase.NotImplemented("get_symbol not implemented for $(T)"))
	end

We can have both possibilities, either the user respects the fields and we have a sort of default getter that get the field if it exists otherwise, it throws an error, or the user can specify a method on its own custom type.

[ocots]

This must be mandatory and so must throw an error if it is not specified by the user:

CTModels.jl/src/nlp/options_schema.jl

Lines 84 to 94 in ac5a9f3

	function _option_specs(::Type{T}) where {T<:AbstractOCPTool}
	return missing
	end
	"""
	$(TYPEDSIGNATURES)
	Convenience overload to accept tool instances.
	"""
	_option_specs(x::AbstractOCPTool) = _option_specs(typeof(x))