SEP add a `%foo_delete` overloading

classic Classic list List threaded Threaded
4 messages Options
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|

SEP add a `%foo_delete` overloading

Dear devs,

After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist overloading are implemented in C/C++ with manual memory management or in Java with garbage collected memory. How to clean-up the associated resources on Scilab mlist deletion ?

I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and give feedbacks !

[1]: https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading

Thanks,

--
Clément

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: SEP add a `%foo_delete` overloading

Hello Clément,

Le 21/12/2018 à 14:19, Clément David a écrit :
Dear devs,

After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist overloading are implemented in C/C++ with manual memory management or in Java with garbage collected memory. How to clean-up the associated resources on Scilab mlist deletion ?

I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and give feedbacks !

[1]: https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading

Thanks,


Thanks for this proposal. I have a couple of questions about it:
In the example that you provide, %foo_delete() is aimed to be called when calling clear().
Using clear looks indeed the most handy and simple. It is the main most known deleting function.

AFAIK The naming convention for the overload of any primitive is %<type>_builtinName.
So, why naming/calling the overload %foo_delete() instead of %foo_clear()?

Are you sure that the bug 10258 is related?
I would rather say that the bug 10277 and the bug 13398 are so.
By the way, 10258's author actually proposes to call %foo_clear().

So, why going out of this convention and regular naming rule?

Best regards
Samuel


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: SEP add a `%foo_delete` overloading

Le 21/12/2018 à 19:40, Samuel Gougeon a écrit :
Hello Clément,

Le 21/12/2018 à 14:19, Clément David a écrit :
Dear devs,

After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist overloading are implemented in C/C++ with manual memory management or in Java with garbage collected memory. How to clean-up the associated resources on Scilab mlist deletion ?

I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and give feedbacks !

[1]: https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading

Thanks,


Thanks for this proposal. I have a couple of questions about it:
In the example that you provide, %foo_delete() is aimed to be called when calling clear().
Using clear looks indeed the most handy and simple. It is the main most known deleting function.

AFAIK The naming convention for the overload of any primitive is %<type>_builtinName.
So, why naming/calling the overload %foo_delete() instead of %foo_clear()?

Are you sure that the bug 10258 is related?
I would rather say that the bug 10277 and the bug 13398 are so.
By the way, 10258's author actually proposes to call %foo_clear().

Sorry: ..so, 10277's author...
_______________________________________________
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: SEP add a `%foo_delete` overloading

Hello Samuel,

I fully agree with `%foo_clear` instead of `%foo_delete` this is simpler to understand from a user
perspective. I edited the wiki page (but preserved the wiki URL) to use this convention. I also
added your bug links to the wiki, a bugzilla search did not list me these ones.

Thanks,

--
Clément

Le vendredi 21 décembre 2018 à 19:42 +0100, Samuel Gougeon a écrit :

> Le 21/12/2018 à 19:40, Samuel Gougeon a écrit :
> > Hello Clément,
> >
> > Le 21/12/2018 à 14:19, Clément David a écrit :
> > > Dear devs,
> > >
> > > After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the
> > > mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist
> > > overloading are implemented in C/C++ with manual memory management or in Java with garbage
> > > collected memory. How to clean-up the associated resources on Scilab mlist deletion ?
> > >
> > > I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and
> > > give feedbacks !
> > >
> > > [1]: https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading
> > >
> > > Thanks,
> >  
> >
> > Thanks for this proposal. I have a couple of questions about it:
> > In the example that you provide, %foo_delete() is aimed to be called when calling clear().
> > Using clear looks indeed the most handy and simple. It is the main most known deleting function.
> >
> > AFAIK The naming convention for the overload of any primitive is %<type>_builtinName.
> > So, why naming/calling the overload %foo_delete() instead of %foo_clear()?
> >
> > Are you sure that the bug 10258 is related?
> > I would rather say that the bug 10277 and the bug 13398 are so.
> > By the way, 10258's author actually proposes to call %foo_clear().
>  
> Sorry: ..so, 10277's author...
> _______________________________________________
> dev mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev