Re: forcing function execution as a core function or from a certain package

[Sergei Steshenko]

----- Original Message -----
> From: Jordi Gutiérrez Hermoso <address@hidden>
> To: Sergei Steshenko <address@hidden>
> Cc: Octave users list <address@hidden>
> Sent: Tuesday, July 10, 2012 11:36 PM
> Subject: Re: forcing function execution as a core function or from a certain 
> package
> 
> On 10 July 2012 16:26, Sergei Steshenko <address@hidden> wrote:
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Jordi Gutiérrez Hermoso <address@hidden>
> 
>>>  On 10 July 2012 16:07, Sergei Steshenko <address@hidden> 
> wrote:
>>>>   notation is allowed and _demand_ that all Octave packages follow 
> the
>>>  scheme.
>>> 
>>>  Yeah, good luck demanding all that. We can't even agree that sumsq
>>>  isn't buggy in core Octave.
> 
>>  You don't have to agree that 'sumsq' is buggy.
>>  Those who think it is buggy will use package export mechanism - that's 
> all.
> 
> The problem is that it would have to be opt-in or else we'd be
> breaking Matlab code. People would have to do something like
> "use_octave_namespaces(1)" in their .octaverc. And people who write
> code would have to check that variable every time to see how they need
> to refer to functions. On top of that, we also need to implement
> Matlab's own mechanism for packages, whether we like how it works or
> not.
> 
> This way lies madness.
> 
> Well, different kind of madnes. At least the madness of having only
> one global namespace is familiar madness. Better the devil you know.
> 
> - Jordi G. H.
>

Sorry, I don't agree. I.e. I think that technically you describe it wrong.


In, for example, Perl, if you do nothing specific, i.e. if you write

our $a_var; # 'our' means global opposed to 'my' which means 'lexical'

sub foo
  {
  ...
  }

both '$a_var' and 'foo' populate/pollute default global namespace. Like in 
Octave.


However, if you write

package Pooh;
our $a_var;
sub foo
  {
  ...
  }

, both '$a_var' and 'foo' now puplate 'Pooh' namespace, and can be accessed 
from wherever as

$Pooh::a_var
Pooh::foo
.

So, if people continue using existing packages without modification, they will 
work as today. And Octave's built-in functions and the ones which comes with 
Octave as .m files will still be in default global namespace.

I.e. today's bad code will work the same (bad) way as today.

However, there will be a possibility to migrate Octave packages to use

Package_name::foo

notation, so namespace collisions in Octave world will be avoided.


And "the madness of having only one global namespace is familiar madness" will 
still be available.

...

I am saying that a reasonably written tool can always be degraded by 
overrides/oveloading. In this context name lookup methods can be degraded to 
single namespace - by some kind of

use Matlab_namespace;

pragma.

In other words, do _not_ write a Matlab clone which is _internally_ clone. 
Write a decent product and on top of it implement _optional_ bug to bug (bug == 
language defect in this case) Matlab compatibility layer.



Regards,
  Sergei.