443316 - XPIDL should support constant string members

Status: RESOLVED WONTFIX

(Core :: XPCOM, enhancement)

Description

[Joshua Cranmer [:jcranmer]]

In one of our interfaces (see bug 413260) it would be very helpful to be able to define a string constant. Because of the string APIs, it would probably make the most sense to limit such members to string types and maybe wstring instead of A{C,UTF8,}String constants.

Example:
interface nsIInterface {
    const string property = "Property";
}

Comment 1

[Joshua Cranmer [:jcranmer]]

FWIW, OMG IDL supports string types (see §3.10.1) as well.

Comment 2

[Boris Zbarsky [:bzbarsky]]

We need this for some new web APIs (e.g. visibility API).

Comment 3

[Philipp von Weitershausen [:philikon]]

(In reply to Boris Zbarsky (:bz) from comment #2)
> We need this for some new web APIs (e.g. visibility API).

Telephony and other APIs will also use string constants.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't think we're going to implement this before the new WebIDL world, and after that I don't think we'll care to backport it to XPIDL.

Comment 5

[Boris Zbarsky [:bzbarsky]]

For what it's worth, having string constants seems to be considered an antipattern nowadays.  WebIDL is dropping support for them, and they will not be present in the visibility API.  I suggest not using them in telephony either.

Comment 6

[Mounir Lamouri (:mounir)]

Do you have any pointer to a discussion explaining why that's considered as an anti-pattern? What should be used instead? integer constants?

Comment 7

[Boris Zbarsky [:bzbarsky]]

See at least discussion starting http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/0040.html

The point is that making named constants for strings just means you have to type more to use the constant than you do to use the string directly, and the constant often hides what's really going on.