On 2018-10-09 00:18, Ryan Schmidt wrote:
> What's the correct way to make a private procedure or variable in a portgroup 
> -- something the portgroup will use internally but that portfiles using the 
> portgroup should not use?>
> I think the answer is to use a namespace. The xcode-1.0 portgroup does:

[...]

> The "_" prefix on the procedure name was meant to convey that it's for 
> internal use only, but if namespaces are what we had been using for that 
> already, I'd like to switch to using that. It looks like only 5 out of 60 
> portgroups use namespaces; maybe we have a lack of information about 
> namespaces preventing the adoption of this feature. I don't see any 
> discussion of Tcl namespaces in the MacPorts Guide.
> 
> Is there anything else I should know about using namespaces in Tcl generally 
> or in MacPorts specifically?

The obvious difference would be the name of the procedure. That is also
the main purpose of namespaces: to provide a hierarchical structure for
naming procedures and variables.

The only advantage of a namespace could be the use of "variable" to
store values that can only be accessed from other procedures in the same
namespace. But I am not sure if there is a usecase for that, because
port groups usually just define additional Portfile options.

As the MacPorts code base has grown over time with many Tcl versions,
namespaces are not used consistently throughout the base source. Most
things are just in the global namespace.

Anyway, yes, namespaces can be used in port groups to keep things
separated and to avoid name clashes in the global namespace.

> Neither a namespace nor the "_" prefix I was using cause the procedures or 
> variables to actually *be* private, as far as I can tell. Ports can still use 
> them if they want to. If I understand correctly, the idea in MacPorts is just 
> to convey which procedures and variables are meant to be internal and whose 
> functionality or existence might change and should not be relied upon by 
> outside callers.

Correct, there is no isolation between PortGroup and Portfile, both are
executed in the same interpreter. As this cannot be enforced, access to
any kind of procedures internal to the port group relies on their
respective naming and the corresponding documentation.

Rainer

Reply via email to