Justin Lebar wrote:
So now you can do
nsCOMPtrnsIFoo foo;
int32_t f = foo-GetFoo();
Why was I expecting this to be Foo()? (Perhaps unreasonably.)
I rejected the first approach because it meant that every call to GetFoo from
XPCOM would need to go through two virtual calls:
Justin Lebar wrote:
%{C++
inline int32_t GetFoo() {
int32_t result;
nsresult rv = GetFoo(result);
MOZ_ASSERT(NS_SUCCEEDED(rv));
return result;
}
%}
Alternative approach?
inline int32_t Foo(int32_t result = 0) {
GetFoo(result);
return result;
}
--
Warning: May contain
On 08/24/2012 02:42 AM, Neil wrote:
Justin Lebar wrote:
So now you can do
nsCOMPtrnsIFoo foo;
int32_t f = foo-GetFoo();
Why was I expecting this to be Foo()? (Perhaps unreasonably.)
Yeah, it should be Foo().
File a bug?
I rejected the first approach because it meant that every
On Tuesday, August 21, 2012 7:36:26 PM UTC-4, Gregory Szorc wrote:
tl;dr We're proposing moving away from Makefile's as the sole source of
the build system definition. This will lead to faster build times.
Bikeshedding^wFeedback on the file format is requested.
The existing build
On Friday, August 24, 2012 10:32:46 AM UTC-4, Ted Mielczarek wrote:
On Fri, Aug 24, 2012 at 9:17 AM, qheaden qhea...@phaseshiftsoftware.com
wrote:
Is there any special reason why an existing build system such as SCcons
couldn't be used as a new build system for Mozilla? I know the
nsCOMPtrnsIFoo foo;
int32_t f = foo-GetFoo();
Why was I expecting this to be Foo()? (Perhaps unreasonably.)
Yeah, it should be Foo().
File a bug?
I considered Foo(), but my concern was that, when we extend this to
attributes which return interfaces (e.g. nsIFoo), then Foo() versus
Gregory Szorc wrote:
4. Native support for list and maps. Make files only support strings.
The hacks this results in are barely tolerable.
5. Ability to handle conditionals. We need to be able to
conditionally define things based on the presence or value of certain
variables.
e.g. if the
Aryeh Gregor wrote:
1) Decide on guidelines for whether a test is internal or reusable.
As a starting point, I suggest that all tests that are regular
webpages that don't use any Mozilla-specific features should be
candidates for reuse. Examples of internal tests would be tests
written in
On Fri, Aug 24, 2012 at 2:08 PM, Brian Smith bsm...@mozilla.com wrote:
Also, are you saying if you are going to write a mochitest, then try to
write a reusable test or if you are going to write a test, write a
reusable test? The reason I ask is that we're supposed to write xpcshell
tests in
For those interested, I've gone ahead and filed a bug to get the keyword
added:
https://bugzilla.mozilla.org/show_bug.cgi?id=785519
Thanks to everyone who provided feedback.
On 12-08-17 10:30 AM, Ralph Giles wrote:
On 12-08-16 6:01 PM, Anthony Hughes wrote:
(CCing dev-quality to reach a
10 matches
Mail list logo
