Feature #10135

lua factory API ideas

Added by Martijn van Beers over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git development version
hardware architecture:


< LotR> boucman: hmm. so there's a section on darktable.modules.format and a seperate one on types.dt_imageio_module_format_t. is
there a reason why both exist?
< boucman> the two are completely different
< boucman> the first one is a hierarchy to acces the functions like dt.modules.format.png() which gives you a png-coniguration object
< boucman> (of type dt_imageio_module_format_png_t)
< boucman> the second is a type to hold all attributes common to all format types (a virtual parent type)
< LotR> but why document them seperately? rather than combine the 'this is the type' and 'this is how to get it' parts?
< boucman> because the doc is documented according to another logical scheme
< boucman> this is the hierarchy of functions you can access
< boucman> this are the types that are used by these functions
< LotR> to me the seperation feels artificial. at least for the format class
< boucman> I disagree, I like to have the darktable tree as a tree without any entries that are not part of the tree
< LotR> more so because the types don't really have a lua name, just the C equivalent you use
< boucman> (on an unrelated note, i'll remove the following attributes from the documentation unless you have a good reason for me
not to : read, has_pairs, has_ipairs, has_length)
< boucman> that can be fixed :P
< LotR> to me darktable.imageio.format.png is the lua name for the type and that is how I wrote that documentation
< boucman> the doc system allows you to rename stuff if you have a better pretty name, I just havn't really used it yet
< boucman> LotR: that's not a type, that's a factory for the type
< boucman> i.e a function that returns a new object of that type each time it's called
< LotR> maybe darktable.modules should be renamed to darktable.factory then
< boucman> not all modules are factories (yes, that's complicated) I'd rather remove dt.module entirely as you suggested yesterday
< LotR> well, the reason I suggested that was because I was confusing the factories and the types apparently
< boucman> yeah, maybe png() should be renamed to new_png()
< boucman> or something like that
< LotR> what about darktable.new_exporter('format.png') or something like that?
< boucman> I don't like magic strings, no...
< LotR> well, if it can be something other than a string, that's better. the main thing is that you have one new_exporter() so you
don't end up with a huge list of api calls that all do essentially the same thing
< LotR> let's not be php :)
< boucman> having one factory per class is a very common idiom in the OO world, that doesn't seem something that should be avoided
< boucman> moreover I don't like functions that do completely differnt things depending on their parameters
< boucman> anyway, as I said previously, please write those remarks down. We are focusing on your HTML right now and if we shoot in
every direction we'll get lost
< LotR> what is 'completely different' about them giving you an exporter object?
< boucman> functions returning different types are odd, and as I said I don't like magic strings (I could create an enum type in C
for that though... hmm, I'll think about that)
< LotR> this is coming from me trying to grok how to generate the docbook I want
< boucman> my point still stand, I am going to work on your "self" problem right now, I don't disagree with the other ones but I
don't want to work on many probles at the same time, it's a very bad idea
< LotR> boucman: it's still all a dt_imageio_module_format_t, just a different subclass
< boucman> LotR: seriously, I don't disagree, I need to think some more about it, I won't work on it until we have dealt with the
"self" problem, write it down, remind me later

Also available in: Atom PDF

Go to top