On 11/9/12 12:52 AM, James Graham wrote:
I know Mozilla use a system where all the tests in a file should pass,
but I don't see how that will work well when you don't control the
tests. If you are manually editing every file when you import it, I
imagine that updating tests will be so time consum
On Fri, Nov 9, 2012 at 11:03 PM, Zack Weinberg wrote:
> I challenge your presuppositions. The average file should need no more
> than one or two `using SYMBOL;` lines per header it includes. Maintaining
> this will not be significantly more difficult than maintaining the existing
> lists of head
On 11/9/2012 10:12 AM, Kyle Huey wrote:
On Sun, Nov 4, 2012 at 11:53 PM, Mook
wrote:
Ping - was this part ever answered?
Did you see my email on November 1st?
- Kyle
Argh; sorry, Thunderbird screwed up threading there and decided your
message was a sibling. That, and I initially read it
On 11/9/12 8:03 PM, Zack Weinberg wrote:
I challenge your presuppositions. The average file should need no more
than one or two `using SYMBOL;` lines per header it includes.
That depends on the structure of the code, no?
For example, until we finish moving over all of the DOM to live inside
On 11/9/12 8:11 PM, Benoit Jacob wrote:
The only issue I see is using namespace at file scope in a _header
file_. I would support a coding style rule against that.
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style#Namespaces
says:
No "using" statements are allowed in h
2012/11/9 Zack Weinberg :
> On 2012-11-09 1:28 PM, Kyle Huey wrote:
>>
>> I reviewed a patch today that had:
>>
>> using namespace mozilla;
>> using namespace dom;
>
>
> The style guide should forbid `using namespace` altogether. Use only what
> you need.
In a given cpp file (in a single TU), as
On 2012-11-09 10:49 PM, Robert O'Callahan wrote:
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg wrote:
The style guide should forbid `using namespace` altogether. Use only what
you need.
I really don't think it should. I do not want to see source files full of
difficult-to-maintain and unn
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg wrote:
> The style guide should forbid `using namespace` altogether. Use only what
> you need.
I really don't think it should. I do not want to see source files full of
difficult-to-maintain and unnecessary "using" boilerplate a la Java
"import".
On 2012-11-09 1:28 PM, Kyle Huey wrote:
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The style guide should forbid `using namespace` altogether. Use only
what you need.
___
dev-platform mailing list
dev-platfor
On 2012-11-09 3:40 PM, Chris Peterson wrote:
On 11/9/12 11:53 AM, Ehsan Akhgari wrote:
using namespace mozilla;
using namespace mozilla::dom;
The style guidelines recommend against using nested namespaces, so doing
what you suggest would make them self-inconsistent.
But we have some nested n
On 11/9/12 11:53 AM, Ehsan Akhgari wrote:
using namespace mozilla;
using namespace mozilla::dom;
The style guidelines recommend against using nested namespaces, so doing
what you suggest would make them self-inconsistent.
But we have some nested namespaces today, so `using` them like Kyle
su
On 2012-11-09 2:43 AM, Henri Sivonen wrote:
Hmm, well, a partial feature might be considered useful for web developers,
but still finishing the implementation may mean changing the way that the
partial implementation works later on, which is likely to break stuff that
rely on it. I'm not sure ho
On 2012-11-09 1:28 PM, Kyle Huey wrote:
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The intent is to pull in the contents of both the mozilla and mozilla::dom
namespaces, but this is only clear if you know that there is no top-level
dom namespace. In the re
On Fri, Nov 9, 2012 at 10:46 AM, Gregory Szorc wrote:
> On 11/9/12 10:28 AM, Kyle Huey wrote:
>
>> I reviewed a patch today that had:
>>
>> using namespace mozilla;
>> using namespace dom;
>>
>> The intent is to pull in the contents of both the mozilla and mozilla::dom
>> namespaces, but this is
On 11/9/12 10:28 AM, Kyle Huey wrote:
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The intent is to pull in the contents of both the mozilla and mozilla::dom
namespaces, but this is only clear if you know that there is no top-level
dom namespace. In the revi
Hi,
There won't be a Gfx meeting next week. We had one last Monday, and
next week the Gfx team is gathering in Vancouver.
For the same reason, by default I expect that we won't meet either on
November 19. Let's say that meeting is cancelled by default, and if we
end up deciding we want to meet on
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The intent is to pull in the contents of both the mozilla and mozilla::dom
namespaces, but this is only clear if you know that there is no top-level
dom namespace. In the review comments I asked the author to write
On Sun, Nov 4, 2012 at 11:53 PM, Mook
wrote:
> Ping - was this part ever answered?
Did you see my email on November 1st?
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Is there any way we can make it so that the prefixed version doesn't
work unless you attempt (and presumably fail) to detect the unprefixed
version?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
On 11/9/2012 8:26 AM, Robert Kaiser wrote:
> AFAIK, the major reason why we did abandon doing that was because moving
> all our interaction with the content to be async was too much work for
> the moment. Isn't that same work required for what you propose?\
No. AIUI, the reason we abandoned electr
Honza Bambas schrieb:
Few reasons:
- I really don't believe we will soon/ever have a good OOP Firefox
implementation
AFAIK, the major reason why we did abandon doing that was because moving
all our interaction with the content to be async was too much work for
the moment. Isn't that same work
2012/11/8 Benoit Jacob :
> 2012/11/8 Henri Sivonen :
>> On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob
>> wrote:
>>> My concrete example is WebGL extensions. These go through 4 stages:
>>> 1. "proposal": no browser must implement it.
>>> 2. "draft": implementations must use a vendor prefix.
>>
>>
2012/11/9 Robert Kaiser :
> Joe Drew schrieb:
>>
>> On 2012-11-06 8:31 AM, Henri Sivonen wrote:
>>>
>>> Therefore, I propose that we adopt the following policy:
>>> 1) APIs that are not ready for use by Web developers shall not be
>>> shipped on the release channel (unless preffed off).
>>> 2)
Joe Drew schrieb:
On 2012-11-06 8:31 AM, Henri Sivonen wrote:
Therefore, I propose that we adopt the following policy:
1) APIs that are not ready for use by Web developers shall not be
shipped on the release channel (unless preffed off).
2) APIs that are shipped on the release channel shall
richardson.balca...@gmail.com schrieb:
I believe my question is, if Mozilla is taking out their app development platform not
'XUL' per se. How would they promote "openness, innovation and opportunity on the
web", only by giving us the opportunity of doing so in extensions on a browser?
What's
I'm strongly in favor of this, I actually even blogged about the subject a
while back: http://blog.avd.io/posts/vendor-prefixes . :)
On Friday, 9 November 2012 09:43:45 UTC+2, Henri Sivonen wrote:
> On Thu, Nov 8, 2012 at 6:56 PM, Ehsan Akhgari wrote:
>
> > On 2012-11-08 1:44 AM, Henri Sivonen
26 matches
Mail list logo
