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
Currently there is a difference between primitive types (i.e., numbers, booleans and strings) and objects, as far as their representation goes. this prevents primitive types from having methods (e.g., we cannot say "string".length())
while it is desirable to keep primitives as lightweight as possible (e.g., to avoid costly overhead when holding collections of them), it is also quite convenient to be able to write expressions such as "string".ends_with("ing") instead of string__ends_with("string", "ing").
we should explore the possibility of having an expression such as:
"string".starts_with("str")
be equivalent to:
str("string").starts_with("str")
where str(.) is the cast operator (or alternatively, the str class constructor overloaded for various types) that returns an object.
while it might also be desirable to do something similar for numbers and booleans, the need is much less clear (e.g., writing 12.sin() or (-12).abs() adds no more clarity than their usual counterparts sin(12) and abs(-12); on the contrary, they are arguably less clear.)
The text was updated successfully, but these errors were encountered:
zxul767
changed the title
automatically cast primitive types to objects when necessary
automatically promote primitive types to objects when necessary
Nov 6, 2022
Currently there is a difference between primitive types (i.e., numbers, booleans and strings) and objects, as far as their representation goes. this prevents primitive types from having methods (e.g., we cannot say
"string".length()
)while it is desirable to keep primitives as lightweight as possible (e.g., to avoid costly overhead when holding collections of them), it is also quite convenient to be able to write expressions such as
"string".ends_with("ing")
instead ofstring__ends_with("string", "ing")
.we should explore the possibility of having an expression such as:
be equivalent to:
where
str(.)
is the cast operator (or alternatively, thestr
class constructor overloaded for various types) that returns an object.while it might also be desirable to do something similar for numbers and booleans, the need is much less clear (e.g., writing
12.sin()
or(-12).abs()
adds no more clarity than their usual counterpartssin(12)
andabs(-12)
; on the contrary, they are arguably less clear.)The text was updated successfully, but these errors were encountered: