Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
NCTM or The Math Forum.



Re: Value classes  do you use them? also syntax questions
Posted:
May 22, 2013 3:32 PM


"Eric Sampson" <ericDOTsampson@gmail.com> wrote in message news:knip0i$q0c$1@newscl01ah.mathworks.com... > "Steven_Lord" <slord@mathworks.com> wrote in message > <kngq7u$2to$1@newscl01ah.mathworks.com>... >> >> >> "Eric Sampson" <ericDOTsampson@gmail.com> wrote in message >> news:kngl1l$gd1$1@newscl01ah.mathworks.com... >> > I posted the below on Answers but got no responses, perhaps the >> > newsgroup is a better forum to discuss this :) >> >  >> > >> > So I can't really recall ever creating a value class, all mine seem to >> > be handle classes. Is that the same as your experience? Unless I'm >> > completely missing something, using value classes seems to be a bit >> > ungainly, because you always have to do two steps like this: >> > >> > foo = MyValueClass(5); % sets a property 'val' >> > foo = foo.double(); >> > plot(foo.val); >> >> Why does the DOUBLE method of the MyValueClass return an object instead >> of a double array? >> > > Sorry Steve, my example was quickly made and obviously confusing; I was > intending the DOUBLE method to just take the current value of the VAL > property and multiply it by two, not do a conversion. I didn't even > realize that DOUBLE/CHAR/etc methods had special meanings, I should have > called my method TIMESTWO to prevent confusion :) > > classdef myValueClass > > properties > val = []; > end > > methods > function obj = timestwo(obj, in) > obj.val = 2 * in; > end > end > > Perhaps the above might explain my original question better now? I can't > return the result of TIMESTWO directly instead of the object, because if I > did that then the modified object (containing the updated VAL) would not > overwrite the original object in the base workspace. I could change the > timestwo method to look like this, function [obj, out] = timestwo(in), but > then I couldn't call it in a chained function call situation like > plot(sin(obj.timestwo(5))) ...
Try:
classdef myValueClass properties val = []; end methods function obj = timestwo(obj, in) obj.val = 2 * in; end function v = double(obj) v = obj.val; end end end
y = myValueClass y = timestwo(y, 5) plot(y, 20, 'Marker', 'o', 'MarkerSize', 25)
You should see a circle at x = 10, y = 20. PLOT will try to call y's DOUBLE method to convert it to a double and use the double precision result to plot. You can see this by trying to PLOT something that can't be converted into a double array, like:
plot({1, 2}, 5)
MATLAB doesn't know how to convert a cell array into a double, so it errors.
>> > As an aside, sometimes it seems like it would be nice to have the above >> > syntax of a handle class, but be able to make independent copies of a >> > given object like a value class... Anyone else think so? >> >> That's what matlab.mixin.Copyable is for. >> >> http://www.mathworks.com/help/matlab/ref/matlab.mixin.copyableclass.html >> > > Thanks Steve, I'll confess that I hadn't figured out the purpose of that > abstract class yet! I think the fact that it was in the 'mixin' package > threw me off, compared to the other abstract handle classes like > hgsetget/dynamicprops which are not  I guess I figured from that fact & > the package name that it had to do with defining a mixin class.
"mixin" is an objectoriented programming term, not something MathWorks invented.
http://en.wikipedia.org/wiki/Mixin
If hgsetget and dynamicprops were introduced today, I suspect they might be named matlab.mixin.hgsetget and matlab.mixin.dynamicprops or something similar.
> Speaking of that, how do you do mixins in MATLAB OOP? Also, how/can you > add methods dynamically to a class and/or instance? > http://www.medihack.org/2011/03/15/intendtoextend/
Some of the techniques from that article are possible in MATLAB. You can inherit (which is how you'd use the matlab.mixin.* classes.) You can kind of simulate adding a "method" to an instance by using a property to store a function handle instead.
% begin myValueClass.m classdef myValueClass
properties val = []; end properties(Hidden) todo = @dummy; end
methods function obj = timestwo(obj, in) obj.val = 2 * in; end function v = double(obj) v = obj.val; end end end
function varargout = dummy(~, varargin) [varargout{1:nargout}] = deal([]); end % end myValueClass.m
>> y = myValueClass; >> y = y.timestwo(pi); >> y.todo() >> y.todo = @why; >> y.todo() To fool the tall good and smart system manager.
Is that a _good_ approach? Maybe not. But it is _an_ approach. Some of the other approaches may also be possible; I didn't read through the whole list in detail.
 Steve Lord slord@mathworks.com To contact Technical Support use the Contact Us link on http://www.mathworks.com



