Because it isn’t the same thing.
Remember, a structure is ‘a memoryblock’, where Xojo knows what is in the box.
‘somestructure’ might use twice as much memory as ‘somethinglse’ for example, and if this was allowed you might end up pushing 200 bytes into an area that is only reserved for 64
Crash waiting to happen.
Classes protect you from that.
You can clone ‘bits of’ something and create a something from a somethingelse safely.
I think this is the key - that Operator_Convert (and perhaps the other Operator_* methods) cannot be used in conjunction with Extends, according to a post some years ago.
Seems like this could be something the compiler could flag as an error. This is also a point that should be made in the documentation, since the information for Extends explicitly mentions built-in classes and intrinsic types are supported, and Operator_Convert’s page says nothing on the matter.
Thanks everybody for the suggestions. I’ve already moved on with my own solution - this thread was more intended to discuss a documentation and/or compiler issue (can’t use Operator_Convert + Extends on an intrinsic type).
It does seem like an omission (if small) from the language. There’s no obvious reason why this functionality is undesirable, or couldn’t be implemented to make the language more consistent end-to-end, from user-created classes to built-in classes like Folderitem to intrinsic types like Integer.
I see it as a hybrid. A memoryblock with a crapton of glue behind it. It’s a class wannabe, but not really. Now, what you have described may well be a bug, or be a reasonable feature request, but I’m not really surprised that it doesn’t work.