Re: Subtype [From: [5.3] Converting a floating point number to integer.]

[Andrew Starks <andrew.starks@...>]

On Thursday, November 20, 2014, Tim Hill <drtimhill@gmail.com> wrote:
> >
> > The above scenario is so common in Lua that it becomes transparent. What I mean is that, I avoid it, work around it, do things in other ways, don't check types, infer types by looking for values, make my own 'subtype` system or... whatever. So, it's not a real problem.
> >
> > BUT, if there was a more formalized, elegant and Lua-esque way to do this, that was at the language level instead of the "loose convention" level (you may choose to take issue with 'loose'), I don't know that things would not be improved.
> >
> > In the case of numbers/integers/integrals/floats, it hasn't mattered to me, very often. It may later. It may matter to a significant number of other people. I don't wish any of the above to be interpreted as an argument for change.
> >
> > All features have costs.
> >
> > -Andrew
>
> Extending type to accomodate sub-types has been discussed here before, and rejected for (if i recall) two reasons:
>
> (1) Adding an additional return value to type() for the sub-type would break code like foo(type(...)), which would cause foo() to start getting extra arguments (bad if foo() expects one or more optional args after the first).
>
> (2) A full type system would imply stuff like interfaces, inheritance and who knows what else.
>
> I think (1) is a valid concern, but (2) is very dubious, since it is basically saying we shouldn’t have a better type system unless we can have a perfect one .. good luck with that!
>
> I’ve always liked the idea of an __type() metamethod in the same way we have __tostring(), but apparently that’s also a bad idea (we go ahead and do that anyway in our systems, replacing type() with a custom version that respects metamethods but restricts type() to one return value to avoid (1)).
>
> —Tim

Tim,

That's exactly what I do, as well. My version of type (typex) takes multiple arguments to match on multiple possibilities: `typex(foo, "string", "string_like_object")`

The truth-y value being the "best" match, given that values can match on multiple types. It works well, although the interface is less than awesome, because I've made it a drop in replacement for type. 

Because Lua is awesome :), this works perfectly well, within my space. 

I keep bringing this up in hopes that someone will discover an elegant mechanism that causes a language-level subtype or classification or capability discovery system to emerge, without ruining Lua or slowing it down. It's all possible now, but ad hoc. 

-Andrew