Operator_Convert to extend a structure?

The documentation seems to suggest that you can use an Operator_Convert to extend a structure:

Function Operator_Convert(extends s as SomeStructure) as SomethingElse

…but it won’t compile:

dim theStructure as SomeStructure
dim theConvert as SomethingElse

theConvert=theStructure ← Type mismatch error

So I guess that’s not a thing? :slight_smile:

You CAN, however, extend a structure with a conventional method:

Function ToSomethingElse(extends s as SomeStructure) as SomethingElse

…which lets you write:

dim theStructure as SomeStructure
dim theConvert as SomethingElse

theConvert=theStructure.ToSomethingElse

If you’re at that level with a structure, you probably should be using a class instead.

4 Likes

I would normally agree, and it’s a bit of pedantic point. But this happens to be a structure that I’m using to interact with an OS API so I’d like to keep it as simple as possible.

If you’re using it to interact with an OS API, then structure is the right tool. But since they’re not an object, you can’t use operator_convert. So extends methods are your best bet.

That is explicitly not the case in the documentation, which is why I’m asking:

" Extension methods can be used with classes or other data types. For example, you can define methods that extend String, Color, and Integer data types. You can also extend arrays."

https://documentation.xojo.com/api/language/extends.html#compatibility

Outside of a class, the name Operator_Convert has no special meaning.


dim theStructure as SomeStructure
dim theConvert as SomethingElse

theConvert=theStructure.Operator_Convert() 

IIRC, the Operator_* methods need to be created right on the class itself… and Structures are not classes.

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 you’ve missed the point of the conversation, or perhaps you’re not familiar with Operator_Convert. :wink:

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.

What are you trying to accomplish?

-Karen

1 Like

OK, but if you are trying to do “fancy” things such as using StructureA = StructureB to invoke Operator_Convert(), one could argue you have left “simple” behind.

Another design pattern would be to have a Class which encloses the Structure, e.g.

Class MyClass inherits Object
  private mData as MyStructure
  function Operator_Convert() as OtherClass  
[... etc... ]

You could even experiment with Operator_Lookup() to make syntax easier, although Operator_Lookup() can also make debugging more difficult

1 Like

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.

Structure is not an intrinsic type.

It behaves exactly like the other intrinsic types (integer, boolean, etc) and not at all like a class or class instance, so I’m going with intrinsic type here. What do you think it is?

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.