Re: Representing a pointer to static in XPConnected JS?

[Nathan Froyd]

On Thu, May 4, 2017 at 12:32 PM, Henri Sivonen  wrote:
> On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd  wrote:
>> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen  wrote:
>>> Is it feasible (with reasonably low effort) to introduce a new XPIDL
>>> type that is a pointer to a non-refcounted immutable static object in
>>> C++ and still gets bridged to JS?
>>
>> You can certainly have static objects with what amount to dummy
>> AddRef/Release methods passed through XPIDL (we do this in a couple of
>> places throughout Gecko), but I don't think you can get away with
>> having a non-refcounted object passed through XPIDL.
>
> Do the AddRef/Release need to be virtual?

Yes.  (I'm not sure how XPConnect would discover the refcounting
methods if they were non-virtual.)

Please note that the static objects with dummy AddRef/Release methods
also implement XPConnect interfaces, i.e. QueryInterface, nsresult
virtual methods, etc.

I think you could possibly make your things a WebIDL interface, which
don't require refcounting, and magically make the WebIDL interfaces
work with XPIDL, but I do not know the details there.

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Representing a pointer to static in XPConnected JS?

[Henri Sivonen]

On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd  wrote:
> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen  wrote:
>> Is it feasible (with reasonably low effort) to introduce a new XPIDL
>> type that is a pointer to a non-refcounted immutable static object in
>> C++ and still gets bridged to JS?
>
> You can certainly have static objects with what amount to dummy
> AddRef/Release methods passed through XPIDL (we do this in a couple of
> places throughout Gecko), but I don't think you can get away with
> having a non-refcounted object passed through XPIDL.

Do the AddRef/Release need to be virtual?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Representing a pointer to static in XPConnected JS?

[Nathan Froyd]

On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen  wrote:
> Is it feasible (with reasonably low effort) to introduce a new XPIDL
> type that is a pointer to a non-refcounted immutable static object in
> C++ and still gets bridged to JS?

You can certainly have static objects with what amount to dummy
AddRef/Release methods passed through XPIDL (we do this in a couple of
places throughout Gecko), but I don't think you can get away with
having a non-refcounted object passed through XPIDL.

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Representing a pointer to static in XPConnected JS?

[Henri Sivonen]

On Thu, May 4, 2017 at 10:08 AM, Henri Sivonen  wrote:
> Is it feasible (with reasonably low effort) to introduce a new XPIDL
> type that is a pointer to a non-refcounted immutable static object in
> C++ and still gets bridged to JS?

My question was underspecified. At minimum, the JS bridging should
have these properties:
1) Returning a non-null const Encoding* from C++ materializes a JS object.
2) Passing the JS object back to C++ materializes the original pointer
on the C++ side.
3) Returning a null const Encoding* from C++ materializes a JS null.
4) Passing a JS null to C++ materializes nullptr.
5) Comparing two JS objects materialized per point #1 with == is true
iff they were materiazed from the same C++ pointer.

Is that kind of thing doable with little effort?

It would be a bonus if the JS objects could come with pre-defined
methods, but that's not strictly necessary.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Representing a pointer to static in XPConnected JS?

[Henri Sivonen]

Our codebase has the conceptual design flaw of representing character
encodings as nsACStrings holding the name of the encoding instead of
having a type-safe representation. This causes ambiguity between
strings that are external protocol text designating an encoding
("label" in spec speak; many labels to one encoding) and internal
strings that have one-to-one mapping to encodings ("name" in spec
speak).

In https://bugzilla.mozilla.org/show_bug.cgi?id=encoding_rs , I'm in
the process of introducing a type-safe representation for encodings:
const mozilla::Encoding* in C++ and Option<&'static
encoding_rs::Encoding> in Rust, which have the same memory
representation and, thus, are zero-toll bridged between C++ and Rust.
(That is, what gets passed around is just a pointer to static. The
pointee's fields are only accessed on the Rust side.)

The next step (as a multiple separate work items and landings) would
be using the type-safe representation throughout the tree. However,
using const mozilla::Encoding* in place of char* or nsACString
throughout C++ code has JavaScript implications, because encodings
occur as arguments (including outparams) in XPIDL methods that are
exposed to JS, too.

Is it feasible (with reasonably low effort) to introduce a new XPIDL
type that is a pointer to a non-refcounted immutable static object in
C++ and still gets bridged to JS?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CodeCoverage Monthly Update

[Chris Peterson]

On 2017-05-03 8:44 PM, Kyle Lahnakoski wrote:

  * Daily coverage reports on coveralls.io [1] and on codecov.io[2].
Which do you like?


Does coveralls.io have a top-down coverage view like codecov.io? That 
view seems more useful for both people that want a global view and 
developers that want to drill down into just their component directories.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform