[vlc-devel] Lua extension and vlc.misc

[Rémi Denis-Courmont]

Le mardi 28 février 2012 21:34:58 Jean-Baptiste Kempf, vous avez écrit :
> How do you detect API breakage?

I think you can test for nulity which is much cleaner and safer. Besides, 
you're not supposed to break the API. So far, we mostly removed buggy stuff.

> > > "copyright"
> > > "license"
> > 
> > Both useless.
> 
> But not dangerous.

Yeah but clutter is clutter. And sooner or later cargo cult will ensure that 
someone uses the function so it cannot be removed anymore. Better not add it 
in the first place.

> > > "datadir"
> > > "userdatadir"
> > > "homedir"
> > > "configdir"
> > > "cachedir"
> > > "datadir_list"
> > 
> > All mostly useless and bad ideas, c.f. other post.
> 
> Disagree. How do you store temp files? How do you do SDs like windirs if
> you do not have access to home?

We don't have a serious plan on exposing Lua modules to the in-VLC Lua 
interpreter, so this point is totally moot.

> > > "action_id"
> > 
> > Same as for the MacOS UI: this should not be exposed.
> > 
> > > Those, I do not know:
> > > "mdate"
> > 
> > Useless in an extension. The only reported use was to reimplement
> > msleep() with mdate() and mwait(), which was stupid.
> 
> The question is not about usage but dangerousity.

I totally disagree.

> > > "mwait"
> > 
> > Mostly harmless but mostly only used for shitty polling code
> > -> bad idea.
> 
> Is there any current working way of doing it differently?

I think so, but that's irrelevant. A bad way is a bad way and we have spent 
far too much effort removing polling. I am SO FED UP with this particular 
topic coming back all the time.

> > My opinion is that none of these should be exposed outside interfaces.
> 
> But, they were exposed. And noone blocked that, before the releases.

You're reinventing history for your convenience.
I opposed merging the extensions in the first place.

> Removing them because they seem useless is not enough.

It is. I have had to deal with cruft for longer than you.

> Blocking dangerous ones, sure.
> Warning for bad ideas ones, if we provide a better way, and then
> deprecating them, sure.

Well, they're already removed then. Problem solved.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis