WriteTable cant handle userdata as tableindex - bug or a feature?

[Bugala]

An example code:

Code: Select all

testtable = {}

For Local n=1 To 3
	ID = CreateBrush(Nil, 10, 10)
	TestTable[ID] = "test"
Next


OpenFile(1, FileRequest("Save Project as:", {path=GetCurrentDirectory(), Mode=#REQ_SAVEMODE}), #MODE_WRITE)
	WriteTable(1, TestTable)
CloseFile(1)

By otherwords, if using userdata as part of the table path, as in this case TestTable[userdata] = var it fails to use writetable.

Fails in both Hollywoods own serializer as well as on JSON serializer.

If using TestTable[n] = userdata, that one works however, so it is not that it cant handle userdata at all, it just cant handle it as part of the table index.

[Bugala]

Also, just noticed that JSON cant handle userdata at all, not even in: TestTable[n] = userdata but this might be expected?

[Bugala]

Additional Notice:
JSON cant handle having Hollywood Dates as Indexes either. It can Handle Hollywood Date as Content, but not as Index:

Code: Select all

SetDefaultAdapter(#ADAPTER_SERIALIZE, "default")

Local ToDate = { Year = 2025, Mon = 1, MDay = 1, Hour = 0, Min = 0, Sec = 0}
ToDate = MakeDate(ToDate)

MyTable = { [TODate] = 1 }

OpenFile(1, "testi", #MODE_WRITE)
WriteTable(1, MyTable)
CloseFile(1)

Hollywoods own inbuilt Serializer however can handle Hollywood Dates as indexes.

[Flinx]

Perhaps the functioning indices are only side effects. If you take the manual literally, then only
positive integers, negative integers, floating point values and strings are suitable as indices, as far as I can see.

[Bugala]

Good to know. Cant quite see how userdata would be essential to save as such, as in for example in the case where I encountered the problem first was that the indexes were holding windowIDs created with NIL, but after saving and loading, I would anyway create those windows again, hence making new userdatas for them.

But the Hollywood Date data is actually essentially useful. That you can want things indexed in time order, and then use the timedata to find them and save them.

Like in my case I have been using Timeindex to save values of cryptocoins on certain dates, and I am accessing this info when I want to know the price of something that happened that day, by using that Day as the Index.

As in:
EurPrice = Coinvalues[date][Coin].Eur
which is storing the Euro value of some coin, like bitcoin, on date X.

might need to make some sort of conversion to number or string for that date, if it is not sure it is going to work in future, as in, if it is now only a side-effect that it happens to work, and behavior could be changed in future.

[airsoftsoftwair]

JSON cant handle having Hollywood Dates as Indexes either. It can Handle Hollywood Date as Content, but not as Index:

This is because you're using #SERIALIZEMODE_HOLLYWOOD (the default mode, see SetSerializeMode()) which does impose some restrictions on key names. In this case it's the space character in the index that's causing problems because that character is reserved when using #SERIALIZEMODE_HOLLYWOOD. If you switch to #SERIALIZEMODE_NAMED, it will be possible to use indices with space characters, so this will work fine:

Code: Select all

SetDefaultAdapter(#ADAPTER_SERIALIZE, "default")
SetSerializeMode(#SERIALIZEMODE_NAMED)

Local ToDate = { Year = 2025, Mon = 1, MDay = 1, Hour = 0, Min = 0, Sec = 0}
ToDate = MakeDate(ToDate)

MyTable = { [TODate] = 1 }

OpenFile(1, "testi", #MODE_WRITE)
WriteTable(1, MyTable)
CloseFile(1)

Also, just noticed that JSON cant handle userdata at all, not even in: TestTable[n] = userdata but this might be expected?

Absolutely. It's impossible to serialize userdata because that's mostly pointing to a block of memory allocated at runtime. Trying to serialize this data doesn't make sense. So clearly a feature.

[Bugala]

Thanks for clarifying this. I agree that saving userdata basically doesn't make sense since reusing it doesn't make sense, and good to know I can still use the Hollywood Date as indexes even in JSON.