Re: Classdef embryonic support

[Ben Abbott]

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).

Ben

changeset.patch
Description: Binary data