This is an important step towards completing #487, but a few more things are needed for this:
Being able to specify int[] as an explicit type specifier. Right now, only implicitly typed int arrays are supported.
Being able to use this for other data types like long[], double[] and string[].
As for the underlying perlang::IntArray class, what I am aiming for here is something a bit more high-level than traditional C-style int[] arrays. They are nice in the sense of being "low overhead" but are also prone to all kinds of C-style memory issues (heap overflow, most notably). Perlang arrays will be more akin to Java or C#-style arrays, which are inherently "safe by design". It should be more or less impossible to use a Perlang array in such a way as to cause the program to crash. Because we don't have a JVM or MSIL interpreter to help us with this, we have to implement the boundary checks on our own.
At the moment, those boundary checks throw (C++) exceptions. We could consider adding more "try"-oriented methods too, like try_get(index, default_value) or even try_get(index, () -> default_value) if we want to be more fancy. Either way, the point is to avoid exceptions and let the caller (by returning a bool) check if the operation was successful or not by different, sometimes more appropriate means than exceptions.
This is an important step towards completing #487, but a few more things are needed for this:
int[]
as an explicit type specifier. Right now, only implicitly typedint
arrays are supported.long[]
,double[]
andstring[]
.As for the underlying
perlang::IntArray
class, what I am aiming for here is something a bit more high-level than traditional C-styleint[]
arrays. They are nice in the sense of being "low overhead" but are also prone to all kinds of C-style memory issues (heap overflow, most notably). Perlang arrays will be more akin to Java or C#-style arrays, which are inherently "safe by design". It should be more or less impossible to use a Perlang array in such a way as to cause the program to crash. Because we don't have a JVM or MSIL interpreter to help us with this, we have to implement the boundary checks on our own.At the moment, those boundary checks throw (C++) exceptions. We could consider adding more "try"-oriented methods too, like
try_get(index, default_value)
or eventry_get(index, () -> default_value)
if we want to be more fancy. Either way, the point is to avoid exceptions and let the caller (by returning abool
) check if the operation was successful or not by different, sometimes more appropriate means than exceptions.