On 04/01/2018 23:47, Gijs Kruitbosch wrote:
On 04/01/2018 22:49, Gabriele Svelto wrote:
On 04/01/18 00:05, Gijs Kruitbosch wrote:
Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver=false=false=
-- sync, the add-ons manager, session store,
On 04/01/2018 22:49, Gabriele Svelto wrote:
On 04/01/18 00:05, Gijs Kruitbosch wrote:
Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver=false=false=
-- sync, the add-ons manager, session store, etc. etc.).
That's not exactly what I meant. JS
On 04/01/18 22:47, Nathan Froyd wrote:
> This is very doable, it just requires some build system hackery: we
> accept preprocessed/generated WebIDL files, and generated IDL files
> would require basically the same approach. I can help with the build
> system hackery if you want to continue
On Thu, Jan 4, 2018 at 4:44 PM, Gabriele Svelto wrote:
> On 04/01/18 22:39, Ben Kelly wrote:
>> Or make your "generator"
>> create the idl which then creates the js/c++?
>
> I tried as that could have worked! Unfortunately it doesn't seem to be
> possible ATM. mach bailed
On 04/01/18 22:39, Ben Kelly wrote:
> We can't have a comment explaining "please add any new constants in
> sequential order in the following list"?
We could, but what about removing one? Also if we have hundreds (or
thousands) the risk that one is accidentally duplicated is significant.
My
On Thu, Jan 4, 2018 at 4:35 PM, Gabriele Svelto wrote:
> On 03/01/18 23:30, Ben Kelly wrote:
> > 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.
>
>
> AFAIK there is no way in
On 03/01/18 23:30, Ben Kelly wrote:
> 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.
AFAIK there is no way in IDL to declare an enum. Constants can be
declared but one needs to manually assign them a
On 2018-01-04 10:00 AM, Nathan Froyd wrote:
…
2) How would one shoehorn this into *DL? The options that come to mind are:
- Separate methods for every observer topic, which sounds terrible
from a code duplication perspective. Though maybe this would be nice
for JS clients, so we could say
On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd wrote:
> On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote:
> > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto
> wrote:
> >> So after validating my approach in that bug (which is almost
On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote:
> On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto 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
>>
On 03/01/2018 23:18, Nihanth Subramanya wrote:
++ from me as well, this sounds awesome.
Ideally, I would like a solution where especially JS-only observer topics don't require a non-artifact build. A JS forwarder for the
"real" observer service may help with that goal, by making the "new"
On 01/04/2018 12:30 AM, Ben Kelly wrote:
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto 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
This is really interesting, thanks for looking at this!
On 03/01/2018 22:09, Gabriele Svelto wrote:
This would have quite a few coding benefits:
- It would make it far easier to retire/rename a topic, since ... JS would
throw.
Why would it? I think it would pass undefined (as the topic
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto 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
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote:
> - It would make trivially simple to document the topics, their subjects
> and payloads. Potentially this could even be integrated with our
> generated documentation and code search tools making developer lives a
> lot
That would be great!
On 03/01/18 23:09, Gabriele Svelto wrote:
> TL;DR this is a proposal to refactor the observer service to use a
> machine-generated list of integers for the topics (disguised as enums/JS
> constants) instead of arbitrary strings.
>
16 matches
Mail list logo