effin' compatibility

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

effin' compatibility

John W. Eaton-6
Recent versions of Matlab have introduced functions like mkdir that
return logical(1) for success and logical(0) for failure.  Octave has
had mkdir for a long time now, but returns double(0) for success and
double(-1) for failure, same as the underlying mkdir system call.

For compatibility, I think we will have to change the behavior of
Octave's functions.

Perhaps we should rename all the posix system calls to be posix_XXX
instead of XXX, then implement the Matlab compatible behavior in .m
files?  Should we just do this (are these functions widely used
anyway?) or should we expend extra effort to try to make the
transition a bit smoother?  I don't really see a way to make a smooth
transition that doesn't also add a lot of hassle for us, so I'm more
in favor of just modifying the code and breaking backward
compatibility with previous versions of Octave in this case.

Comments or suggestsions?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: effin' compatibility

Paul Kienzle
On Sep 28, 2005, at 12:42 PM, John W. Eaton wrote:

> Recent versions of Matlab have introduced functions like mkdir that
> return logical(1) for success and logical(0) for failure.  Octave has
> had mkdir for a long time now, but returns double(0) for success and
> double(-1) for failure, same as the underlying mkdir system call.
>
> For compatibility, I think we will have to change the behavior of
> Octave's functions.
>
> Perhaps we should rename all the posix system calls to be posix_XXX
> instead of XXX, then implement the Matlab compatible behavior in .m
> files?  Should we just do this (are these functions widely used
> anyway?) or should we expend extra effort to try to make the
> transition a bit smoother?  I don't really see a way to make a smooth
> transition that doesn't also add a lot of hassle for us, so I'm more
> in favor of just modifying the code and breaking backward
> compatibility with previous versions of Octave in this case.
>
> Comments or suggestsions?
>

Maybe we can introduce the notion of namespaces to sort this out?

Something like "namespace octave2" means that all subsequent
function lookups for the remainder of the current context
are done in the octave2 namespace.

This is too much work for this case alone, but this is a
recurring problem, so a general solution would be nice.  There
are a lot of details to work out about the syntax an semantics
of namespaces so it wouldn't be a quick fix.

- Paul

Reply | Threaded
Open this post in threaded view
|

Re: effin' compatibility

Andy Adler
On Thu, 29 Sep 2005, Paul Kienzle wrote:

> Maybe we can introduce the notion of namespaces to sort this out?
>
> Something like "namespace octave2" means that all subsequent
> function lookups for the remainder of the current context
> are done in the octave2 namespace.
>
> This is too much work for this case alone, but this is a
> recurring problem, so a general solution would be nice.  There
> are a lot of details to work out about the syntax an semantics
> of namespaces so it wouldn't be a quick fix.

  I would love octave to have namespace support.

  I would love octave to have namespaces compatible with matlab
     OO classes.

  I would love it if matlab OO syntax didn't suck.

So the catch is that compatible object syntax would
introduce suckiness into octave. Does anyone have ideas
around this one?

As far as I can tell, Matlab OO is based on Perl's mapping of
  Method Name <=> File Name. However, I detest the fact
that the syntax doesn't tell you exactly what is going on.

   For example. This is clear
      x= my_funky_variable_type( args, ...)
      y= x.inverse();  % this calls a special inverse.m

   This is not
      x= my_funky_variable_type( args, ...)
      y= inverse(x); % is this a normal, or a special inverse?

Suggestion:

   Would it be possible to allow methods to be called in octave
   by doing
      y= x.inverse( args ) or y=x->inverse( args )
   as well as
      y= inverse(x, args)

--
Andy Adler <[hidden email]> 1(613)562-5800x6218


Reply | Threaded
Open this post in threaded view
|

Re: effin' compatibility

John W. Eaton-6
On 29-Sep-2005, Andy Adler wrote:

|   I would love octave to have namespace support.
|
|   I would love octave to have namespaces compatible with matlab
|      OO classes.
|
|   I would love it if matlab OO syntax didn't suck.
|
| So the catch is that compatible object syntax would
| introduce suckiness into octave. Does anyone have ideas
| around this one?

The other catch is that introducing our own namespace syntax or
functionality is likely to cause future compatibility problems.

If we want a better language, I'm afraid we are going to have to look
at something completely different rather than modify Octave/Matlab.
That doesn't mean that Octave would have to be abandoned as useless,
it just means that we need a good way to call Octave from the better
language so that we can continue to use the Octave/Matlab code that we
have, while being liberated from the suckiness of the current system.

| As far as I can tell, Matlab OO is based on Perl's mapping of
|   Method Name <=> File Name. However, I detest the fact
| that the syntax doesn't tell you exactly what is going on.
|
|    For example. This is clear
|       x= my_funky_variable_type( args, ...)
|       y= x.inverse();  % this calls a special inverse.m
|
|    This is not
|       x= my_funky_variable_type( args, ...)
|       y= inverse(x); % is this a normal, or a special inverse?

So you would not like lisp/scheme generic functions?

| Suggestion:
|
|    Would it be possible to allow methods to be called in octave
|    by doing
|       y= x.inverse( args ) or y=x->inverse( args )
|    as well as
|       y= inverse(x, args)

Yes, probably possible, but then this gets back to the issue of future
incompatibilities biting you in places that you normally don't want to
be bitten.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: effin' compatibility

John W. Eaton-6
In reply to this post by Paul Kienzle
On 29-Sep-2005, Paul Kienzle wrote:

| Maybe we can introduce the notion of namespaces to sort this out?
|
| Something like "namespace octave2" means that all subsequent
| function lookups for the remainder of the current context
| are done in the octave2 namespace.

I'm hesitant to do this because of the future compatibility problems
that might arise.

| This is too much work for this case alone, but this is a
| recurring problem, so a general solution would be nice.  There
| are a lot of details to work out about the syntax an semantics
| of namespaces so it wouldn't be a quick fix.

In this case, I decided to go for just changing the behavior for
compatibility.  It currently affects only mkdir and rmdir, which are
probably not used in the 2 or 3 output mode very often.

jwe