On Jan 14, 2013, at 9:58 PM, Michael Goffioul wrote:
> On Mon, Jan 14, 2013 at 9:56 PM, Ben Abbott <
address@hidden> wrote:
> On Jan 13, 2013, at 3:47 PM, Michael Goffioul wrote:
>
> > On Sat, Jan 12, 2013 at 7:02 PM, Ben Abbott <
address@hidden> wrote:
> > On Jan 12, 2013, at 11:54 AM, Michael Goffioul wrote:
> >
> > > On Sat, Jan 12, 2013 at 11:34 AM, Ben Abbott <
address@hidden> wrote:
> > > On Jan 6, 2013, at 10:35 PM, Michael Goffioul wrote:
> > >
> > > > On Tue, Jan 1, 2013 at 8:09 PM, Michael Goffioul <
address@hidden> wrote:
> > > > Hi,
> > > >
> > > > Just a heads up to let people know I've spent some time during my christmas holiday to start working again on the classdef branch. I've just pushed some changes to implement initial support for handle-class and value-class semantic. Don't expect too much out of it, but maybe some of you are interested in giving it a try. For instance, I'd be more than happy if someone would write unit tests for the classdef support.
> > > >
> > > > Did anybody have a chance to give it a try? Although far from finished, it's already somehow usable (you can define classes, methods, properties, use inheritance and make superclass calls; it also supports handle and value semantics).
> > > >
> > > > Michael.
> > >
> > > The classef branch now builds on MacOS X! :-)
> > >
> > > I'm new to classdef, so I borrowed an example from the Mathworks site, made some modifications, and added some tests (see the attached payment.m)
> > >
> > > However, I'm not sure how to go about adding tests to the sources. Perhaps syntax like below be added to the test feature?
> > >
> > > %!classdef payment
> > > %! properties
> > > %! rate;
> > > %! term;
> > > %! principle;
> > > %! end
> > > %! methods
> > > %! function obj = payment (r, t, p)
> > > %! obj.rate = r;
> > > %! obj.term = t;
> > > %! obj.principle = p;
> > > %! end
> > > %! function amt = amount (obj)
> > > %! i = obj.rate / (12 * 100);
> > > %! amt = (obj.principle * i) / (1 - (1 + i)^(-obj.term));
> > > %! end
> > > %! end
> > > %!endclassdef
> > >
> > > For now, tests can be added to a classdef m-file, but I don't see how that would be committed.
> > >
> > > See how tests are designed for the old-style class in test/classes/.
> >
> > That's simple enough. I've attached a changeset with some basic tests. Look ok?
> >
> > > Thanks for giving it a try, Ben. I'm fully aware of the limitations and all these are on my (huge) TODO list. At the moment, what is supported is:
> > > - classdef file parsing
> > > - handle/value class semantic
> > > - class inheritance
> > > - property/method access with dot-notation
> > > - property/method access restriction (public, protected, private, cell array of classes)
> > > - property accessors
> > > - array of objects(not complete, though)
> > >
> > > Michael.
> >
> > I'll start tinkering more with classdef. As I come up to speed, I'll add more tests.
> >
> > Thanks, Ben.
> >
> > Maybe classed tests should be put into their own subdir, to avoid confusion. Also it might be clearer if the class names were chosen to reflect what is actually tested, or whether it's a base/abstract/derived/... class (e.g.: BaseHandleClass, DerivedValueClass, BaseSealed, privateProp, sealedMethod...) and similarly for property/method names.
> >
> > Michael
>
> Michael,
>
> Is placing the classdef tests in a classdef subdirectory ok?
>
> The attached just moves the changeset I've already pushed. If this location is ok, I'll start populating additional test (but with more appropriate names).
>
> Yes, that should be fine. Thanks again for your help.
>
> Michael.