I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
Ah I think my wording has probably confused matters - Model is the custom type, DisplayingRoom and Failure are values that custom type can have. (These are known as type variants)
DoorState and AlarmState are also custom types.
This might help clarify things a little:
Consider Bool - that is a type that can have a value of either True or False, and would be represented (and I imagine probably actually is represented in the source code!) as:
Ooohh yes, that makes perfect sense! A custom type can have any... custom... values you make up, they don't have to be defined separately anywhere else. I get it now. My mental block was that I was still thinking of the Model type as a record, just because it was named Model. LOL.
I guess I'm starting to see why "custom types" is a better name than "union types" (what they used to be in 0.18). Thanks for the update to 0.19!
I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
Glad that helped! I can totally see how that caused confusion.
And yeah, I think the change of naming convention from union to custom is a big positive. Custom type is a phrase that can be easily understood without even having any real understanding of the language at all! :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Also, looking at it more carefully... how is the top-level
DisplayingRoomtype defined? I'm sure that's a ridiculously basic question...Ah I think my wording has probably confused matters -
Modelis the custom type,DisplayingRoomandFailureare values that custom type can have. (These are known astype variants)DoorStateandAlarmStateare also custom types.This might help clarify things a little:
Consider
Bool- that is atypethat can have a value of eitherTrueorFalse, and would be represented (and I imagine probably actually is represented in the source code!) as:Does that answer your question? :)
Ooohh yes, that makes perfect sense! A custom type can have any... custom... values you make up, they don't have to be defined separately anywhere else. I get it now. My mental block was that I was still thinking of the
Modeltype as a record, just because it was named Model. LOL.I guess I'm starting to see why "custom types" is a better name than "union types" (what they used to be in 0.18). Thanks for the update to 0.19!
Glad that helped! I can totally see how that caused confusion.
And yeah, I think the change of naming convention from
uniontocustomis a big positive.Custom typeis a phrase that can be easily understood without even having any real understanding of the language at all! :)