[Scilab-Dev] SEP: Object oriented programming under scilab

[Michael Baudin]

Hi,

The current SEP may be splitted into 4 separate SEPs :
- update the datastructure we are working on
- input/output arguments
- overload macros
- an OO system for Scilab (which includes the inheritance part of the SEP)

While the implementation of the first 3 SEPs may require weeks of work
(and may be available during 2009 or with v6) , the implementation of 
the Graal 4th may
take months or even years (and may be available during 2010/2011, after v6).
In between, one should be able to design better Scilab
scripts, even if a full OO system is not available.

The solution suggested by YC to manage the "this" implicit statement
seems to be elegant. Here is an example of what would
be possible with this feature :

Function newperson= Person_new()
  newperson=tlist(["t_data","field1","configure"])
  newperson.field1=""
  newperson.configure=person_configure
Endfunction
Function person_configure(key,value)
  if key=="field1" then
    this.field1=value
  end
Endfunction
P1= Person_new()
p1.configure("field1","toto")
 
What is strange here, is that the developper has no clue while reading
the "person_configure" function, that the "this" implicit variable is 
not a bug.
It may also happen that current scripts allready use the "this" variable,
which may transform these scripts into bugs when the feature will
be available.
One solution may be to define a new type of function, say "listfunction" for
example, in which the "this" variable is implicitely defined as an 
input/output
variable.

listfunction person_configure(key,value)
  if key=="field1" then
    this.field1=value
  end
endlistfunction

The solution I explored on the wiki was limited by the fact that
current scilab scripts does not allow arguments to be both
input and output. The current Scilab features allow to do
this, but are not so easy to use :
http://wiki.scilab.org/Emulate_Object_Oriented_in_Scilab

I suggest here two solutions to provide such a feature :
- an alias system "upvar", which makes a link between
a variable name and a variable upper in the call stack.
This command is available in Tcl.
- a pointer system, similar to C pointer, and which
seems to be available in Matlab for functions only.

Sol#1
function person_configure(p1name)
  upvar1 p1name p1
  p1.name="linus"
end function
p1=tlist("type","name")
person_configure("p1")
 
Sol#2
function person_configure(pp1)
  P1=*pp1
  P1.name="linus"
end function
p1=tlist("type","name")
person_configure(@p1)
 
This is the header of the upvar command :

upvar ?level? otherVar myVar

"This command arranges for one or more local variables in the current
procedure to refer to variables in an enclosing procedure call
or to global variables. The upvar command simplifies the implementation
of call-by-name procedure."

Another possibility would be to implement the "inputvarname"
command available in Matlab, but the feature is not as powerful
as "upvar", and not as clear as "@/*".

The solution suggested by SL for object orientation seems
to be simple and clear.
In practical situations, the additionnal features will be
necessary :
- distinguish the instance methods from the class methods,
- distinguish the instance variables from the class variables,
- explicit management of creation and destruction.
This may be an example of an abstract optim class, which
may serve as a base for all optimization which are based
on an initial guess.

class optim
  variable initialguess
  classvariable numofoptim 0
  constructor ()
    numofoptim = numofoptim + 1
  endconstructor
  method setinitialguess(variable)
    initialguess = variable
  endmethod
  method res = getinitialguess()
   res = initialguess
  endmethod
  classmethod res = getnumoptim()
   res = numofoptim
  endclassmethod
endclass

The following may be a BFGS class, which extends the
optim class by adding a bfgs matrix.

class optim_bfgs(optim)
  variable bfgsmatrix
  constructor ()
    bfgsmatrix = zeros()
  endconstructor
  method solve()
   x0=initialguess
    // A BFGS method...
  endmethod
  method updatematrix()
    // update the bfgs matrix
  endmethod
endclass

The use of this class may be done with the following
lines.

o1=new(optim_bfgs)
o1.setinitialguess(zeros(5))
o1.solve()
free(o1)

But OO may mean much more than this as we all know :
- multiple inheritance,
- abstract interfaces.
Multiple inheritance may be implemented with a OO
model based on delegation.

Another feature will is linked is namespaces, because we
cannot think that the number of features in Scilab can increase
in one single, global, namespace. Notice that current function names
are limited to 24 characters, so that a naming convention
may be quite limited.

Regards,

Michaël