You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe slightly controversial but prototypes and the baggage that comes with it adds a lot of overhead. Do we really need it? We can embrace a more functional style instead of "OOP" that works like old JS. There's already no class syntax and I kind of doubt there's significant OOP code written in Mond anyway.
The challenge is without types and overloading we'd need to have uniquely named function or namespace them under an object. For example, consider all the builtin prototypes for strings, arrays, etc. We need to be able to get the length of strings and arrays, so we could have a generic length function or could have String.length and Array.length instead.
Alternatively maybe we can go down the Lua route a bit with the : operator. It's kind of similar to the |> operator we already have where it transforms x.y(z) into x.y(x, z) (while only evaluating x once). However we wouldn't have a separate operator for that I think... kind of like universal function call syntax.
The text was updated successfully, but these errors were encountered:
Maybe slightly controversial but prototypes and the baggage that comes with it adds a lot of overhead. Do we really need it? We can embrace a more functional style instead of "OOP" that works like old JS. There's already no class syntax and I kind of doubt there's significant OOP code written in Mond anyway.
The challenge is without types and overloading we'd need to have uniquely named function or namespace them under an object. For example, consider all the builtin prototypes for strings, arrays, etc. We need to be able to get the length of strings and arrays, so we could have a generic
length
function or could haveString.length
andArray.length
instead.Alternatively maybe we can go down the Lua route a bit with the
:
operator. It's kind of similar to the|>
operator we already have where it transformsx.y(z)
intox.y(x, z)
(while only evaluatingx
once). However we wouldn't have a separate operator for that I think... kind of like universal function call syntax.The text was updated successfully, but these errors were encountered: