[Scilab-Dev] SEP add a `%foo_delete` overloading

[Clément David]

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
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev