Mike Innes wrote: > As a rule, you generally want to translate > > object.func(args...) > > into > > func(object, args...) > > State can be kept in the fields of the object, and accessed using the > dot-notation as above. Julia doesn't have class-base inheritance but you > can still do objects just fine, albeit with slightly different notation. > > I'm not sure if I've understood you correctly – does that help? > > On Wednesday, 7 May 2014 16:46:19 UTC+1, Neal Becker wrote: >> >> I've always used the following rule in languages such as python and c++ >> >> If an object has state, use a class. Otherwise use a function. >> >> In languages lacking classes (and objects) e.g., FORTRAN, state must be >> maintained outside of the object. This is ugly and error prone. >> >> How is this addressed in julia? >> >>
Thanks for the answers. I think for this purpose the encapsulation of data (state) into the objects is what is important. So a function F can operate on object a F(a) and as a side-effect, the state of a is updated. So for example, if fira is and FIR filter object, then output = Filter (fira, input) can update the internal state of a as well as returning the output. Further, anyone can query the state of fira as: fira.state So IIUC julia is fine for this. I will miss the ability to do output = fira (input), but I probably can live with it.
