Introducing new data types and IPC messages for scripted JS speech recognition APIs (Speech CL2.0)

content/public/common/speech_recognition_error.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_PUBLIC_COMMON_SPEECH_RECOGNITION_ERROR_H_
 #define CONTENT_PUBLIC_COMMON_SPEECH_RECOGNITION_ERROR_H_
+#pragma once
 
 namespace content {
 
 // This enumeration follows the values described here:
 // http://www.w3.org/2005/Incubator/htmlspeech/2010/10/google-api-draft.html#speech-input-error
 enum SpeechRecognitionErrorCode {
   // There was no error.
   SPEECH_RECOGNITION_ERROR_NONE = 0,
   // The user or a script aborted speech input.
   SPEECH_RECOGNITION_ERROR_ABORTED,
@@ skipping 13 matching lines @@
 enum SpeechAudioErrorDetails {
   SPEECH_AUDIO_ERROR_DETAILS_NONE = 0,
   SPEECH_AUDIO_ERROR_DETAILS_NO_MIC,
   SPEECH_AUDIO_ERROR_DETAILS_IN_USE
 };
 
 struct CONTENT_EXPORT SpeechRecognitionError {
   SpeechRecognitionErrorCode code;
   SpeechAudioErrorDetails details;
 
-  SpeechRecognitionError(SpeechRecognitionErrorCode code_value)
+  SpeechRecognitionError()

[Satish, 2012/04/27 10:04:41]

style guide forbids inlining constructors in header files, so can you add a .cc
and move the body of these into that?

[hans, 2012/04/27 10:53:30]

I think in practice it's fine to avoid the extra .cc file as long as the
style-checker plugin doesn't complain.

See for example jam's second comment in
http://codereview.chromium.org/9972011/diff/45003/content/public/browser/spee...
where he questions the need to out-of-line the ctor/dtor.

The style guide rule is there to avoid inlining complex constructors.

[Satish, 2012/04/27 11:08:02]

Thats what I thought earlier, but the style guide above says "Even for simple
classes, putting the function in the .cc file helps avoid this when someone
later adds a new variable to the class." - which is true. I'm happy either way
but want to be consistent, and per style guide consistent means not having any
inline constructors.

jam@, do you have a strong preference to inline constructors? If so, should we
allow it in the style guide and not leave it as is?

[jam, 2012/04/27 14:43:26]

For files in content/public we have tried to avoid cc files as much as possible,
only adding them so that clank doesn't complain. The reasoning is that it's a
public directory, so (ideally) should just be headers

[Satish, 2012/04/27 14:45:34]

Cool, makes sense. Is it ok to mention this in the style guide as the one
exception to the inlining rule?

+      : code(SPEECH_RECOGNITION_ERROR_NONE),
+        details(SPEECH_AUDIO_ERROR_DETAILS_NONE) {
+  }
+  explicit SpeechRecognitionError(SpeechRecognitionErrorCode code_value)
       : code(code_value),
-        details(SPEECH_AUDIO_ERROR_DETAILS_NONE) {}
+        details(SPEECH_AUDIO_ERROR_DETAILS_NONE) {
+  }
   SpeechRecognitionError(SpeechRecognitionErrorCode code_value,
                          SpeechAudioErrorDetails details_value)
       : code(code_value),
-        details(details_value) {}
+        details(details_value) {
+  }
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_COMMON_SPEECH_RECOGNITION_ERROR_H_