Re: How to implement IPT strel.m ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: How to implement IPT strel.m ?

John W. Eaton-6
[I'm moving this to the maintainers list.  --jwe]

On  3-Aug-2004, David Bateman <[hidden email]> wrote:

| Octave doesn't have classes. The fact is in discussion with Paul
| Kienzle, I've thought about the problem a bit. Implementing all of the
| infrastructure for classes in octave is pretty easy with the code that
| already exists.  What seems to me to be the hard bit is modifiying
| Octave itself so that the directory "@class" is interpret as a private
| directory that contains all of the functions specific to the class.
|
| I'm not sure I understand all that would have to change within Octave
| to support private directories and so don't won't to tackle this
| problem, until I either completely understand how to implement private
| directories or someone has already done it.

The @class directory hack is similar to the private function
subdirectory hack.  It will require some changes to the file lookup
code (in liboctave/pathsearch.cc).  Some time ago, I pared down the
kpathsearch code and converted it C++ (use C++ strings, new/delete,
etc.) in anticipation of having to modify it to handle these new
features that are specific to Octave.  Also, I never liked the fact
that there was no clean separation between the basic file lookup code
and the TeX-specific features of the kpathsearch code.  Now the code
for file lookup that is actually used in Octave is much smaller than
before.  It is only about 3200 lines long in the file kpse.cc and the
file in CVS has about 600 lines that are not currently used, so it
could be even smaller.  We should be able to adapt this code and the
symbol lookup code in Octave's symbol table to do the right thing when
looking for functions once we define the proper search order.

I think the other tricks in supporting classes will be integrating the
dispatch code with the core of Octave and supporing the strange class
relationship hierarchy that Matlab has with "inferiorto" and
"superiorto" (this will affect the way function searches are performed
given the type of the first argument).

jwe


Reply | Threaded
Open this post in threaded view
|

Re: How to implement IPT strel.m ?

David Bateman-3
According to John W. Eaton <[hidden email]> (on 08/03/04):

>
> The @class directory hack is similar to the private function
> subdirectory hack.  It will require some changes to the file lookup
> code (in liboctave/pathsearch.cc).  Some time ago, I pared down the
> kpathsearch code and converted it C++ (use C++ strings, new/delete,
> etc.) in anticipation of having to modify it to handle these new
> features that are specific to Octave.  Also, I never liked the fact
> that there was no clean separation between the basic file lookup code
> and the TeX-specific features of the kpathsearch code.  Now the code
> for file lookup that is actually used in Octave is much smaller than
> before.  It is only about 3200 lines long in the file kpse.cc and the
> file in CVS has about 600 lines that are not currently used, so it
> could be even smaller.  We should be able to adapt this code and the
> symbol lookup code in Octave's symbol table to do the right thing when
> looking for functions once we define the proper search order.

Exactly. Any ideas what the right search order is. Do private functions
take precedence? What about those in a class? And what about structures
like @class1/@class2 that Matlab permits? Do they make any sense without
Simulink? Should we support them?

> I think the other tricks in supporting classes will be integrating the
> dispatch code with the core of Octave and supporing the strange class
> relationship hierarchy that Matlab has with "inferiorto" and
> "superiorto" (this will affect the way function searches are performed
> given the type of the first argument).

The stuff like superiorto, subsref, etc could be done with the
octave_value class that handles the function overloading. Stuff like
subsref is easy as the subsref of the overloading class
(octave_overload) would be called and it would hand it off to the
class specific m-file; if it doesn't exist -> error message.
superiorto, etc might be handled in two different ways. Either all of
the functions expected to be used might be overloaded in
octave_overload, and then if the function to perform this doesn't exist
the function itself reports the error. Otherwise at the time of the
registration of the class we could search the class specific code for
the functions to overlaod and only overload those functions.

The second way is perhaps cleaner, but has the disadvantage that new
dot-m files in the class forthe binops and unary ops won't be seen
till after a restart of octave. This might be a bit counter intutitive
to some users. The first way, avoids this but instead has the problem
of how to treat operations with mixed classes of arguments.

Cheers
David

--
David Bateman                                [hidden email]
Motorola CRM                                 +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


Reply | Threaded
Open this post in threaded view
|

Re: How to implement IPT strel.m ?

Paul Kienzle

On Aug 4, 2004, at 3:40 AM, David Bateman wrote:

> According to John W. Eaton <[hidden email]> (on 08/03/04):
>>
>> The @class directory hack is similar to the private function
>> subdirectory hack.  It will require some changes to the file lookup
>> code (in liboctave/pathsearch.cc).  Some time ago, I pared down the
>> kpathsearch code and converted it C++ (use C++ strings, new/delete,
>> etc.) in anticipation of having to modify it to handle these new
>> features that are specific to Octave.  Also, I never liked the fact
>> that there was no clean separation between the basic file lookup code
>> and the TeX-specific features of the kpathsearch code.  Now the code
>> for file lookup that is actually used in Octave is much smaller than
>> before.  It is only about 3200 lines long in the file kpse.cc and the
>> file in CVS has about 600 lines that are not currently used, so it
>> could be even smaller.  We should be able to adapt this code and the
>> symbol lookup code in Octave's symbol table to do the right thing when
>> looking for functions once we define the proper search order.
>
> Exactly. Any ideas what the right search order is. Do private functions
> take precedence? What about those in a class? And what about structures
> like @class1/@class2 that Matlab permits? Do they make any sense
> without
> Simulink? Should we support them?

subfunctions > private functions > class functions > builtin functions


Reply | Threaded
Open this post in threaded view
|

Path search [ was Re: How to implement IPT strel.m ? ]

Josep Monés i Teixidor
In reply to this post by David Bateman-3
Hi

Note: my insight on Octave code is below 0, so please just ignore if I
say something silly :)

On dc, 2004-08-04 at 09:40, David Bateman wrote:

> According to John W. Eaton <[hidden email]> (on 08/03/04):
> >
> > The @class directory hack is similar to the private function
> > subdirectory hack.  It will require some changes to the file lookup
> > code (in liboctave/pathsearch.cc).  Some time ago, I pared down the
> > kpathsearch code and converted it C++ (use C++ strings, new/delete,
> > etc.) in anticipation of having to modify it to handle these new
> > features that are specific to Octave.  Also, I never liked the fact
> > that there was no clean separation between the basic file lookup code
> > and the TeX-specific features of the kpathsearch code.  Now the code
> > for file lookup that is actually used in Octave is much smaller than
> > before.  It is only about 3200 lines long in the file kpse.cc and the
> > file in CVS has about 600 lines that are not currently used, so it
> > could be even smaller.  We should be able to adapt this code and the
> > symbol lookup code in Octave's symbol table to do the right thing when
> > looking for functions once we define the proper search order.
>
> Exactly. Any ideas what the right search order is. Do private functions
> take precedence? What about those in a class? And what about structures
> like @class1/@class2 that Matlab permits? Do they make any sense without
> Simulink? Should we support them?

overloaded functions are also similar.

From matlab docs:
*Variable
*Subfunction
*Private function
*Class constructor
*Overloaded method
*M-file in the current directory
*M-file on the path, or MATLAB built-in function

So path search has to take in account:
 * First argument (to handle classes and overloaded functions)
 * Other arguments too (if I understand correctly inferiorto and
superiorto make necessary take into account other arguments)
 * Directory of current function being executed (which is cwd if running
from the cmd line)

Where should all this checks go?

1.- As arguments in a function in dir_path ?
2.- Being handled inside load_fcn_from_file which would call find_all?
3.- Being handled inside load_fcn_from_file which would call
find_first_of using search strings like @datatype/hello.m ?

I like the last one, because dir_path don't gets to tied on this things
and it hasn't the overhead of the 2d one, but I haven't got much
knowledge about Octave internals.

A problem with 3 is if we are inside a class directory, for instance...
how to match if we use relative paths?

Regards,
--
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

signature.asc (189 bytes) Download Attachment