On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd <nfr...@mozilla.com> wrote:
> On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly <bke...@mozilla.com> wrote: > > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto <gsve...@mozilla.com> > wrote: > >> So after validating my approach in that bug (which is almost ready) I've > >> thought that it might be time to give the observer service the same > >> treatment. First of all we'd have a list of topics (I've picked YAML for > >> the list but it could be anything that fits the bill): > > > > Could we use our existing idl/webidl/ipdl for this? It would be nice > not to > > have to maintain another code generator in the tree if possible. > > I don't understand this objection on two levels: > It wasn't an objection. It was a question. If possible, can we use something we already have? The answer can be "no". > 1) Why does maintaining another code generator in tree hurt anything? > We have many one-off code generators for specific purposes: > > https://searchfox.org/mozilla-central/search?q=GENERATED_ > FILES&case=false®exp=false&path=moz.build > > Some of these use non-Python generators (e.g. the a11y files and gfx > shaders), but there are probably enough to count on multiple hands. > > I would expect modifications of the code generator to be infrequent, > and the code generator itself is liable to be a screenful or so of > straightforward code. > Sure, but having someone understand and able to modify additional code generators does require additional effort. Its not impossible, but it makes it harder. So it would be nice to avoid if we can. If we can't avoid it, then ok. > - WebIDL enums (I think), which would carry a large space penalty and > make everything that wants to use the observer service depend on code > from dom/, which seems undesirable. > - IDL enums, which aren't reflected into JS, so we'd need some custom > work there. > Yea, I was mostly thinking webidl or idl enums. The enums could be stuck on an idl interface as constants, no? Anyway, I was mostly just asking that we consider these options before writing something new. If they're not a good fit, then so be it. Thanks. Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
