| Store | Cart

Re: [TCLCORE] TIP 412

From: Trevor Davel (Twylite) <twyl...@crypt.co.za>
Sun, 20 Jul 2014 21:25:18 +0200
Hi,

On 2014/07/18 06:40 PM, Kevin Kenny wrote:
> My understanding of how a 'package locale' was intended to work was that> [mclocale] would place its settings in the caller's namespace. This> namespace could be the namespace of a package (which is not terribly> useful), or a TclOO object instance, or a namespace created specifically> to track the settings of a session (both of which are useful). Tying it> to a namespace gives the caller control over the scoping mechanism. This> should be pretty familiar, because it's the way we identify the scope of> practically everything else that we've designed recently.> The key point, though, is that it's the caller's locale, not> [clock]'s. Having a specific locale for [clock] would be pretty useless,> it might as well be process-global.
I don't think it's the caller's locale at all - it's the system's locale 
or the user's locale.  The caller is a piece of code, and under most 
circumstances code does not "have a locale" (unless you are actually 
doing a locale-specific computation).  I'm not splitting hairs here - 
I'm talking about a different scoping mechanism.

To start with the obvious: the fact that we need to consider a changing 
locale at all makes it clear that locale is a dynamic (runtime) concern, 
not a lexical one.

In the case of a program serving users from different locales, we must 
associate a path of execution with a locale.  There are may ways to do 
this, for example we could serve each user in a different thread (or 
coroutine) and use a thread-local (or coroutine-local) locale; or we 
could pass to each function  a user object the encapsulates the locale; 
or we could use a dynamically scoped variable.  In no case though do we 
use the lexical scope of the command.

I cannot see how a session namespace can provide a solution here; nor 
how 'package locale' gets us closer to one?  To me a dynamic 'package 
locale' is just a way to provide a complicated locale structure 
orthogonal to the claimed use cases (we clearly need a way to discover 
per-package messages, but I question the need to change locale per 
package/namespace).

Regards,
Trevor




------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

Recent Messages in this Thread
Trevor Davel (Twylite) Jul 15, 2014 09:44 pm
Kevin Kenny Jul 16, 2014 02:12 am
Harald Oehlmann Jul 17, 2014 09:02 am
Trevor Davel (Twylite) Jul 17, 2014 09:41 am
Harald Oehlmann Jul 17, 2014 09:48 am
Harald Oehlmann Jul 17, 2014 09:49 am
Trevor Davel (Twylite) Jul 17, 2014 10:06 am
Harald Oehlmann Jul 18, 2014 07:33 am
Martin Lemburg Jul 18, 2014 01:03 pm
Kevin Kenny Jul 18, 2014 04:40 pm
Trevor Davel (Twylite) Jul 20, 2014 07:25 pm
Joe English Jul 17, 2014 06:04 pm
Donal K. Fellows Jul 19, 2014 09:45 pm
Messages in this thread