Re: forward declarations vs includes

[Boris Zbarsky]

On 1/12/17 2:30 AM, gsquel...@mozilla.com wrote:

This way all users of SomeClass only need to include SomeClass.h, not 
SomeType.h, when they want to call SomeClass::foo.


They don't need to have SomeType.h included merely to call 
SomeClass::foo.  They have the forward-declaration in scope, so they can 
pass along SomeType* values they get from somewhere, and don't even have 
to forward-declare it themselves to do so.  e.g. this would be a 
perfectly sane consumer of SomeClass:


  #include "SomeClass.h"
  #include "SomeOtherClass.h" // also forward-declares SomeType

  void PassLongFoo(SomeClass* inst)
  {
inst->foo(SomeOtherClass::getSomeType());
  }

where SomeOtherClass has a static getSomeType() returning SomeType*. 
None of this requires any of the files involved to include SomeType.h.


What _does_ require including SomeType.h is if you plan to construct a 
SomeType, or manipulate SomeType instances in some way.  But in that 
case, you really should be including SomeType.h yourself instead of 
relying on SomeClass to do it for you, in my opinion.



I can see how nice this can be for users of SomeClass.


Until SomeClass stops using SomeType and those users stop compiling 
because they are still doing things with it but no longer getting the 
include courtesy of SomeClass.  This is especially pernicious with 
unified compilation, because it can take some time to notice.



So I personally still prefer the coding style as is


I do too.

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

forward declarations vs includes

[gsquelart]

Controversy!

Our beloved coding style reads:
"Forward-declare classes in your header files instead of including them 
whenever possible."
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#CC_practices

I guess the main goal is to keep build times lower by reducing the number of 
nested includes.

Now I've heard the view is that if a public function takes a type, the header 
should include the necessary dependent header for that type instead of just a 
forward declaration, so that users of that function will not have to include it 
themselves.
(But forward-declaring types only used internally by the header's own types is 
still fine.)

E.g., for:
  class SomeClass
  {
  public:
void foo(SomeType* aPtr);
  private:
SomeOtherType* mValue;
  }

Our coding style says that we should just have `class SomeType; class 
SomeOtherType;` above that class.

My friend would prefer `#include "SomeType.h" class SomeOtherType;`.
This way all users of SomeClass only need to include SomeClass.h, not 
SomeType.h, when they want to call SomeClass::foo.


My personal thoughts:

I can see how nice this can be for users of SomeClass.

But then, maybe not all includers of SomeClass.h would use foo (assuming 
there's more in that file).
Also some callers of SomeClass::foo may also just be passing a pointer (e.g. a 
proxy), so they don't need to include "SomeType.h" either.
And of course, this could add to the overall build time.

So I personally still prefer the coding style as is, but I wanted to discuss 
this here to see how others feel...

Flame away!
Gerald
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [dev-servo] Intent to vendor Servo in mozilla-central

[Henri Sivonen]

On Wed, Jan 11, 2017 at 3:04 PM, Ted Mielczarek  wrote:
> On Wed, Jan 11, 2017, at 06:03 AM, Henri Sivonen wrote:
>> Does that mean that crates under third_party/rust/ are going to have
>> their entire histories imported in the future? Currently, they only
>> have vendoring-time snapshots.
>
> I'm unaware of any plans to do this. I'd expect us to have a distinction
> between:
> 1) Crates where Mozilla is the primary author but the repository of
> record is somewhere else like GitHub (like Servo).

(I'm writing a crate that I expect to be categorized like this in the
future, which is why I'm interested.)

> These will probably
> be vendored specially into somewhere other than third_party/rust as
> Servo is. There are other non-Rust projects that want this as well, such
> as Azure (the graphics library) and devtools.
...
> 3) Crates where Mozilla is not the primary author, pulled in as
> dependencies from crates.io. These will continue to be vendored into
> third_party/rust. Note that crates.io currently doesn't require crates
> to specify a VCS repository or revision or anything like that, so I'm
> not sure it's completely tractable to vendor these dependencies with
> full history anyway.

Most crates currently under third_party/rust/ are already show at
least one Mozilla employee as a co-owner on crates.io (and, I'm
guessing, primary author), so at present, we've already used process
for category #3 for crates that arguably are category #1.

I'm unconvinced that it makes sense to distinguish between category #1
and category #3 in terms of placement in the m-c directory structure
on people org chart grounds. I can see a technical case for placing
history-imported and history-not-imported crates differently in the
m-c directory structure, though, but it's not immediately obvious (to
me) that people org chart situation should be the deciding factor in
whether it's worthwhile to import the history of a given crate.

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

Is it possible to implement "click to play" for Adobe Flash in XULRunner app?

[段垚]

Hi,

In Firefox, "click to play" can be enabled by setting pref 
"plugin.state.flash" to 1.


However, when I do this in a XULRunner app, flash plugin is disabled 
completely.


Is this feature unavailable to XULRunner? If so, how can I implement it?


Thanks.


Duan Yao.


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

Please consider whether new APIs/functionality should be disabled by default in sandboxed iframes

[Boris Zbarsky]

When adding a new API or CSS/HTML feature, please consider whether it 
should be disabled by default in sandboxed iframes, with a sandbox token 
to enable.


Note that this is impossible to do post-facto to already-shipped APIs, 
due to breaking compat.  But for an API just being added, this is a 
reasonable option and should be strongly considered.


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

Re: [dev-servo] Intent to vendor Servo in mozilla-central

[Ted Mielczarek]

On Wed, Jan 11, 2017, at 06:03 AM, Henri Sivonen wrote:
> Does that mean that crates under third_party/rust/ are going to have
> their entire histories imported in the future? Currently, they only
> have vendoring-time snapshots.

I'm unaware of any plans to do this. I'd expect us to have a distinction
between:
1) Crates where Mozilla is the primary author but the repository of
record is somewhere else like GitHub (like Servo). These will probably
be vendored specially into somewhere other than third_party/rust as
Servo is. There are other non-Rust projects that want this as well, such
as Azure (the graphics library) and devtools.
2) Crates whose repository of record is mozilla-central. This is likely
to be primarily Gecko glue code, like the nsstring[1] crate.
3) Crates where Mozilla is not the primary author, pulled in as
dependencies from crates.io. These will continue to be vendored into
third_party/rust. Note that crates.io currently doesn't require crates
to specify a VCS repository or revision or anything like that, so I'm
not sure it's completely tractable to vendor these dependencies with
full history anyway.

RE: your other point, we have a few bugs around verifying licensing on
vendored crates, as well as implementing some sort of "trust checking"
to verify what we're pulling in from crates.io:
https://bugzilla.mozilla.org/show_bug.cgi?id=1316990
https://bugzilla.mozilla.org/show_bug.cgi?id=1322798

-Ted

1. https://dxr.mozilla.org/mozilla-central/source/xpcom/rust/nsstring
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [dev-servo] Intent to vendor Servo in mozilla-central

[Henri Sivonen]

On Wed, Jan 4, 2017 at 1:35 AM, Gregory Szorc  wrote:
> Also, I anticipate the techniques and tools used to import Servo's history
> and keep it "synchronized" have uses outside of Servo. Our current
> mechanisms for keeping upstream/third party projects in sync with
> mozilla-central are not well standardized. I'd really like the work to
> support Servo to be used for other projects as well. This potentially
> includes a future where certain directories in mozilla-central are
> effectively developed on GitHub or are using other "non-standard"
> workflows.

Does that mean that crates under third_party/rust/ are going to have
their entire histories imported in the future? Currently, they only
have vendoring-time snapshots.

If so:

1) Will the history before import likewise be hidden from bisect?

2) How are we going to review the history of genuinely third-party
crates for stuff we shouldn't host? E.g. are we going to do licensing
review on the past revisions of an imported crate in addition to
vetting its current state?

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