What's the way to derive from structs

[AaronKParticipant]

Hi guys. I just updated to Monkey 1.1.04 and all of a sudden my struct extends don’t work. Is there any way to do this any more or do I basically have to compose a struct inside and reimplement the methods?

Cheers

[LarsParticipant]

You cannot extend a struct. Change it to a class.

[AaronKParticipant]

But I have it as a struct so I can have value semantics given the bizarre choice to have structs by value and classes by ref?!?!?!

[abakoboParticipant]

Structs are copied by value, that’s why you are not supposed to make very big struct, it would slow it down. This makes another problem with inheritance, it would slow down it’s speed benefit if it could have ‘extends’. However you can use ‘extension’, but then it’s always the same struct name. The ‘extension’ keyword is not documented but you can find some examples in the forum:http://monkey2.monkey-x.com/forums/topic/possible-to-add-method-to-rect-with-extention/

[AaronKParticipant]

Thanks, extends is what what I wanted to do; I just needed to add some member functions to Vec2i

I don’t see the logic of not allowing extends on a Struct – it seems pretty arbitrary. If there’s nothing virtual, no need for a virtual function table so no overhead.

One thing I’ve found as I’ve gotten into Monkey2 a bit more is that documentation is really lacking. Or maybe it’s the search function in the docs that doesn’t work well. Either way I often can’t find what I’m after

[papgarParticipant]

Mark has his reasons

http://monkey2.monkey-x.com/forums/topic/struct-goofiness/

[AaronKParticipant]

Seems like a lot of restrictions to avoid type slicing; something common in another languages (Especially C/++).

The way structs are is trading one “issue” for another. That is, you have to continually look at the declaration of your types to check whether they are by value or ref which I don’t think should ever have to be the case; code should be self documenting. It’s also now forcing people who want to use virtual functions to have by ref (And effectively heap allocated objects) which is taking away their control over performance.

I actually wonder if it would have been better for Monkey (and c++ to be honest), to just not allow assignment that causes slicing. I’m having trouble right now, thinking of a single use case where I have ever needed to do this. i.e. It’s always been mistake.

[Simon ArmstrongParticipant]

Aaron, if I was to author a book I would try an include such sentiments. Apparently a lot of GPU optimisation these days is around collections of arrays, not arrays of collections.

In terms of encouraging good behaviour due to some methodological beliefs, I often find it very annoying in monkey languages. As an example, open source but with enforced private access to underlying standard modules. For hacks and hackers it feels like an extremely authoritarian stance considering the lack of opt out for less law abiding / obsessive citizens.

[Author]

Posts