Why can't I have a string array as a computed property?

I would like to add often used lists like Months() to my projects in a localisable and reusable way.

So I wanted to add Months() as String to a module. Easy enough. But I would still need to init it, and more importantly remember to init it.

So I try a computed property - however when I try to make a computed property Months() as String then the compiler complains.

What would be the best way to make those arrays in a reusable and localised form, eg Months?

Or am I going about this all wrong?

Use methods instead of computed properties.

use OVERLOADED methods instead of computed properties

Because it doesn’t work.
It has been a pain for many years, that computer properties can’t be arrays, especially all properties in plugins!
So you often end providing two things:

Something as String()
Something(index as integer) as string
SoemthingCount as Integer

Why? Because Something can return an array, but you can’t directly use it with index.

I think what he is looking for is

function Something as String()
sub Something(assigns s as String())

indeed it IS curious since if you declare a computed as

      Computed Property Foo as Integer()

you’d think that should work

And, if the IDE didnt muck up the code that gets written to compile it might

But, is messes it up so if you do this you get a compile error

Window1.Foo() Declaration
Syntax error
Private Property Foo() As Integer()

perhaps if they fixed that it would work ?

I honestly cant think of any reason it wouldn’t
However, the getter would return the whole array
The setter would be passed an array

EDIT : bah scratch that
seems aaron pondered this one way back and I even had checked

FYIW… Swift has no problem

  var zString : [String] =[]
    public var myString : [String] {
        get { return zString }
        set { zString = newValue }

and it works for ANY Datatype

arrays in Xojo are a reference type under the hood and thats where the issues come in (as noted in Aarons blog post about them)

To quote from Aaron’s book:

Imagine, if you will, some code that looks like this:

someClass.someComputedProperty.Append( someItem )

Since the array is computed, that means that someItem is being appended to an array that will be immediately destroyed after the call ends because nothing else is holding a reference to it. Could you tell that from looking at the code? Probably not!

But why would the array be destroyed when you save it in mArray?

IF you store it then you may not have that issue
But there’s no requirement to store it

Its computed so it could be created on the fly and then you have a “copy” that is not retained

In a really simple example of the issue if someClass.someComputedProperty is

Getter() as String()
     return array ( "1", "2" )

then the getter is called, the array returned and appended to and thrown away

Nothing holds on to the reference

I think thats the argument Aaron is making

EDIT : ah yeah thats basically it
When you get to the end he ev notes this case where IF the getter is returning some stored property

In the former case, you are creating a new object every time you call SomeProperty’s getter. In the latter case, you are returning a property that’s backed by storage on the class. So the latter case is safe because modifications are actually retained. It’s the former case that causes all of the heartache!

Can the compiler check if the array is backed by a property? Eg the getter returns the property?

I suppose it could - it just adds complexity to the compilation process

it just doesnt and never has