What is an opaque value?

Question

Sometimes I see in documentation or specifications that a certain value, in general, string, can, or should, be considered opaque. What does this really mean? What are the characteristics that define a string opaque?

To quote, it is worth referring to RFC 3986, also discussed in this question, which states that a path segment is considered opaque by generic syntax.

[...] a path segment is considered Opaque by the Generic syntax

Just as it is valid to refer to documentation on MDN on the attribute id that says the attribute value is a string opaque.

This attribute’s value is an Opaque string

Is the meaning of opaque in both situations the same? Because, still in the MDN documentation there is, just after the quoted passage, the following statement:

[...] this Means that web Author must not use it to Convey any information

That, translating, would be that the author should not use the attribute id to provide any information. whereas path of the URL is the requested resource identifier, is it correct to state that this is also opaque by not loading any information? If so, a user-friendly URL, which loads attribute values into the path (for example, /user/edit/1), break the definition of opaque value?

Optional for responses: cite other values that are considered opaque.

Answer 1

In computer science, the concept of opaque is known in 2 moments, in the type of opaque data and in the opaque pointers.

In RFC 3986 the term Opaque is cited 5 times within a phraseal context:

1:

URI Scheme Specifications can define Opaque Identifiers by
disallowing use of Slash characters

2:

after the Scheme Component delimiter (":") is considered Opaque to URI Processing

3:

treating it as an Opaque string from the double-Slash to the first terminating delimiter

4:

Aside from dot-Segments in hierarchical paths, a path segment is
considered Opaque by the Generic syntax.

5:

All Ferences to "Opaque" Uris have been replaced with a Better Description of how the path Component may be Opaque to Hierarchy.

RFC 3986 does not specify exactly what terminology was used, see this other document , it defines a terminology . If the author of RFC wanted to represent this same context applying in conjunction with the term string or another object is possible to interpret as if it were really referring to the type nature, since it was applied in these phrases as adjetivo and not substantivo, in the case of an opaque string variable, or an opaque URI(object).

To understand the opaque type we need to see its applied concepts, differentiate from the opaque pointer and define transparence.

An opaque type is any type whose internal details are not visible to the application using the type.

In computer science, an opaque data type is a data type whose concrete data structure is not defined in an interface. That is to say, with hidden information, since their values can only be manipulated by calling subroutines that have access to information missing. The specific type representation is hidden from users and the visible implementation is incomplete. A data type whose representation is visible is called transparent. Data types opaque are often used to implement data types abstract. ¹

In C, C++ and Objective-C, you can tell the compiler that a type will be defined later using a direct statement ²:

// declaração direta de um struct em C, C++ and Objective-C
struct Foo;

// declaração direta de class em C++:
class Bar;

// declaração direta de class em Objective-C:
@class Baz;

The opaque data type in general refers to an incomplete structure (which has been declared but not defined), such as struct Foo;. Nothing is known about Foo, but it can be used in some cases like Foo& and Foo*. Ref. (https://stackoverflow.com/a/6477523/3706998)

Opaque data types are not the same as opaque pointers, some programming languages, such as C, allow the declaration of opaque hands , whose size and fields are hidden from the customer. The only thing the customer can do with an object of such a type is to take its memory address, to produce an opaque pointer.

The most classic example is FILE * returned by fopen() of the language C. The type FILE * is not required to be complete, and therefore compatible and compliant programs should treat it as if it were incomplete, i.e., an opaque pointer. The opaque pointer design pattern is also known as Pimpl (Pointer-to-implementation)(pointer to implementation).

#include <stdio.h>

int main()
{
    FILE * fh = fopen( "foo", "r" );
    if ( fh != NULL )
    {
        fprintf( fh, "Hello" );
        fclose( fh );
    }
    return 0;
}

Already a transparent value is used for where something is present, but you cannot see it. Opaque is used where something is present, but you cannot see inside it to inspect its inner workings.³

Ref. Friedman, Daniel P.; Wand, Mitchell, (2008). Essentials of Programming Languages (3rd ed.). MIT Press. p. 34-42. ISBN 978-0-262-06279-4.

By the method of assimilation we can try to understand what exactly represents this opaque value for the context. In the context of RFC 3986 makes sense when we use the opaque type definition (Opaque datatype) referenced above.

Aside from dot-Segments in hierarchical paths, a path segment is
considered Opaque by the Generic syntax.

If we bring it to Portuguese and replace the term opaque with its meaning in the "Paque" context of computer science.

In addition to point segments in hierarchical paths, a path segment is > considered without an apparent implementation by generic syntax.

Taking into account these aspects of the opaque type, when the term was used opaque, we are led to believe that "string Opaque" would be a value that is present but not implemented, or that has not been defined, is hidden in the implementer, its size definitions, structure and methods are not apparent.

By virtue of what was mentioned the opaque value is one that does not have a definite or undeclared form, but that its internal structure exists and is recognized by the syntax, but is unknown and/or without interpretation.

Whereas the URL path is the resource identifier requested, it is correct to state that this is also opaque by no carry no information?

The only certainty we have is that it is possibly a string, but if we assign it to the context I defended above, it would be correct to state that it is opaque for not revealing details of its implementation or structure.

For example in a URI /user/update/:id+ we could have:

/user/edit/1

and

/user/edit/1,2,3,4

In the first case we would have an update of a single resource, in the last the update of multiple resources. The nature of this implementation is opaque, without a visible definition.

If so, a user-friendly URL, which loads attribute values in the path (for example/user/Edit/1), break the definition of opaque value?

It wouldn’t break the definition because you’re still not exposing the value implementation. We can say it’s still an opaque value.