Comments on: The Gift of Property Cheer https://blogs.mathworks.com/developer/2017/12/22/property-validation/?s_tid=feedtopost Developing, testing, and integrating production grade software using MATLAB. Tue, 02 Jan 2018 15:29:04 +0000 hourly 1 https://wordpress.org/?v=6.2.2 By: Andy Campbell https://blogs.mathworks.com/developer/2017/12/22/property-validation/#comment-14890 Tue, 02 Jan 2018 15:29:04 +0000 https://blogs.mathworks.com/developer/?p=1190#comment-14890 Hmm, interesting on the spam protection math problem. I’ll let the right team know about it and pass on any tips that I may have. In the meantime, let me know if it continues to happen.

]]>
By: David Barry https://blogs.mathworks.com/developer/2017/12/22/property-validation/#comment-14856 Sat, 30 Dec 2017 11:16:03 +0000 https://blogs.mathworks.com/developer/?p=1190#comment-14856 Perfect, thanks for the reply and tips Andy.

Oh by the way, the spam protection sum checker kept failing on me the other day. I only managed to submit the post by entering a random number (not the answer to the sum shown).

]]>
By: Andy Campbell https://blogs.mathworks.com/developer/2017/12/22/property-validation/#comment-14846 Tue, 26 Dec 2017 18:35:04 +0000 https://blogs.mathworks.com/developer/?p=1190#comment-14846 Hey David,

The way I think about it is that it is actually the string class who has given other types the ability to be convertible to it. As such, it has given the rest of MATLAB the ability to be substitutable for anything that expects and requires string. I probably wouldn’t be the right person to delve into the specifics as to why the string class has chosen this behavior, but I do know that there has been a lot of analysis about the string class and the different usage models and it no doubt is a result of making sure this behavior supports all of the ways that people would like to use strings (one quick example, it enables great operations like:

 >> "file" + [1:10] + ".txt"

ans = 

  1×10 string array

    "file1.txt"    "file2.txt"    "file3.txt"    "file4.txt"    "file5.txt"    "file6.txt"    "file7.txt"    "file8.txt"    "file9.txt"    "file10.txt""file" + [1:10] + ".txt"

Anyway, the point is that the string class has enabled this behavior, for perhaps a multitude of reasons, but it has the right to define this behavior against its interface. Another class that reuses string has to work harder, perhaps for good reason, to “deny” the string class this aspect of its interface.

Note that for your own class, the behavior you expected will occur unless your own class has made itself convertible into another type. Thus this aspect of the property validation works for both sets and gets by default. It just requires that you are aware of the contract of your collaborators, in this case string.

I think that your suggestion of a property attribute, such as

 properties(DisableAutoConversion)

or something like that has some merit and I will create an enhancement request to that effect. In the meantime you certainly can still leverage a setter method to validate the type explicitly…but I would actually then suggest only adding the specific class check and rely on the property validator for other aspects such as size or other properties. This would set you up more nicely for the future I predict.

Hope that helps!
Andy

]]>
By: David Barry https://blogs.mathworks.com/developer/2017/12/22/property-validation/#comment-14832 Sat, 23 Dec 2017 10:09:51 +0000 https://blogs.mathworks.com/developer/?p=1190#comment-14832 Looking forward to trying out this new feature when we upgrade in the new year.

Thanks for pointing out the data type conversion gotcha as that definitely would have tripped me up. It would be interesting to know why this design decision was made. I can’t think of a usecase in my own code where I would want anything other than error if I wasn’t setting a string. I guess I’ll have to stick to setters for now. Maybe some optional setting could be added to the property def in the future to turn off data type conversion and force strict type matches?

]]>