Question about constructor function

[t.tutiya]

What is the difference between the following two functions?

#cat := class:
#    Name:string
#    Sound:string

MakeCat1<constructor>(name:string, sound:string) := cat:
    Name := name
    Sound := sound

MakeCat2(name:string, sound:string):cat = cat:
    Name := name
    Sound := sound

If they are the same, wouldn’t the constructor specifier be meaningless?

[ok_studios]

First off, I think this is a really great question, and one I am looking at right now too.

Within the context of the code you’ve provided, I would say it does not appear to make any difference. And does not generate an error. But within other contexts, it seems to have a major role. Most notably, if you look at the Persistent Stats Tutorial, they make heavy use of constructors, and say that constructors are required because “Verse persistence does not allow classes containing variable fields to be persistable.” In replicating just a small portion of that code, it will not work without a constructor. See pic.

[t.tutiya]

Thanks for the reply!
Unfortunately, that code can be given a return type to avoid compile errors

[ok_studios]

Does this post help you?

What's the point of Verse constructors?

Design of Verse constructors is a bit weird. Coming from C# if they would be similar we could use them as: MyClass := my_class(DataForConstructor:my_data): MyClassVar := OtherVar This makes them very easy to use and discover. After typing my_class( we get a suggestion list of all possible constructors. Additionally it’s possible to make default constructor private and inaccessible, forcing us to use custom constructor. Verse constructors seem to not differ much from functions? Other then …

In it, the UltimateLambda concludes with this:
“If you don’t intend to use a constructor function with other constructor functions, you may be better served with a plain function.”

P.S. I did remove the constructors from the Persistent tutorial example, and it worked with just plain functions as you showed, as long as the return type was manually specified.

[Kamyker]

@ok_studios

I did remove the constructors from the Persistent tutorial example, and it worked with just plain functions as you showed, as long as the return type was manually specified.

This is kinda wrong, it compiles correctly but doesn’t do deep clone when using normal function as constructor as shown in Persistent tutorial example.

土屋つかさ

[ok_studios]

Interesting. Is it safe to say then that constructors would be required in the Persistence example and that a plain function would be insufficient? Thanks!

[t.tutiya]

@ok_studios

In it, the UltimateLambda concludes with this:
“If you don’t intend to use a constructor function with other constructor functions, you may be better served with a plain function.”

I had missed that post. Thanks!

[Kamyker]

They would be fine but you shouldn’t use them with <constructors>, was confirmed as a bug in recent Q&A

[t.tutiya]

From: Ask Epic : Verse

Ask Epic: Verse - March 28 @ 10:00 AM ET

That looks like a bug (I’m making a bug report for it currently). It won’t act at all like the version in an archetype instantiation, but instead will just act like a plain function invocation, producing a new instance of cat with Name as "foo" and Sound as "boo".

That looks like a bug (I’m making a bug report for it currently). It won’t act at all like the version in an archetype instantiation, but instead will just act like a plain function invocation, producing a new instance of cat with Name as "foo" and Sound as "boo" .