Re: Tcl namespaces and private procedures and variables
On 10.10.18 04:09, Ryan Schmidt wrote: Well, you could say that's also the purpose of the naming conventions we've used in other portgroups. The naming of the github.setup procedure and the github.homepage option and so forth are intended to convey that they are part of the github portgroup. I realize that from Tcl's standpoint the "." in the name is no different than any other character, so technically these is just a top-level procedures and options like any a port could define, but conceptually they're meant to be seen as part of the portgroup. exactly I assume that for example if I migrate the github portgroup to use a namespace, I will hide internal procedures like handle_tarball_from inside the namespace, while keeping things a Portfile is intended to use, like github.setup and github.homepage, outside of the namespace. Tcl namespaces can contain commands, variables and other namespaces. Namespaced items can be always addressed with the full path (starting with "::") and sometimes without the namespace prefix (e.g. inside a "namespace eval", or when namespaced items are exported). Namespace-exported commands are often used as the (public) interface to a package, while the non-exported commands are regarded as package-internal. The Tcl library contains many examples of namespace usages, see e.g. [1] [1] https://core.tcl.tk/tcllib/artifact/812f146bfc1a12bb
Re: Tcl namespaces and private procedures and variables
On Oct 9, 2018, at 17:45, Rainer Müller wrote: > 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. Well, you could say that's also the purpose of the naming conventions we've used in other portgroups. The naming of the github.setup procedure and the github.homepage option and so forth are intended to convey that they are part of the github portgroup. I realize that from Tcl's standpoint the "." in the name is no different than any other character, so technically these is just a top-level procedures and options like any a port could define, but conceptually they're meant to be seen as part of the portgroup. I assume that for example if I migrate the github portgroup to use a namespace, I will hide internal procedures like handle_tarball_from inside the namespace, while keeping things a Portfile is intended to use, like github.setup and github.homepage, outside of the namespace.
Re: Tcl namespaces and private procedures and variables
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
