Recursive extraction on a function's identifier

classic Classic list List threaded Threaded
2 messages Options
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Recursive extraction on a function's identifier

Hello,

Let
function s = myfun()
   clear s
   s.a = %pi
   s.b = %z
endfunction

Presently, we get

--> myfun.a
Attempt to reference field of non-structure array.

--> myfun().a
 ans  =
   3.1415927

The type of the symbol myfun as a function is known when calling myfun.a, isn't it?

So, is there a technical or a usage reason to not understand implicitly myfun.a as myfun().a ?
As well, couldn't we expect an error message routing the user to defining %function_e()
(unless Scilab provides a default definition) ?

Thanks
Samuel


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|

Re: Recursive extraction on a function's identifier

Hello Samuel,

IMHO the function call without parenthesis `myfun` instead of `myfun()` notation is a function call helper handy for some functions and while playing with the REPL *but* using it inside macros or as real code is not a good idea for readability.

As a rationale, I always describe the `foo an argument` syntax is a handy way for listing files and is really a corner-case rewritten to `foo("an_argument")` before execution. Similarly I describe the dot operator as rewritten to a string extraction.

Thanks,

--
Clément

> -----Original Message-----
> From: dev <[hidden email]> On Behalf Of Samuel Gougeon
> Sent: Tuesday, June 25, 2019 1:38 PM
> To: List dedicated to development questions <[hidden email]>
> Subject: [Scilab-Dev] Recursive extraction on a function's identifier
>
> Hello,
>
> Let
> function s = myfun()
>    clear s
>    s.a = %pi
>    s.b = %z
> endfunction
>
>
> Presently, we get
>
>
> --> myfun.a
> Attempt to reference field of non-structure array.
>
> --> myfun().a
>  ans  =
>    3.1415927
>
> The type of the symbol myfun as a function is known when calling myfun.a, isn't
> it?
>
>
> So, is there a technical or a usage reason to not understand implicitly myfun.a as
> myfun().a ?
> As well, couldn't we expect an error message routing the user to defining
> %function_e() (unless Scilab provides a default definition) ?
>
>
> Thanks
> Samuel
>
>

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev