[Tcl-bugs] [ tcl-Feature Requests-672050 ] function interface design and namespaces

[SourceForge.net <no...@so...>]

Feature Requests item #672050, was opened at 2003-01-21 13:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=672050&group_id=10894

Category: 80. Thread Package
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Elfring (elfring)
Assigned to: Zoran Vasiljevic (vasiljevic)
Summary: function interface design and namespaces

Initial Comment:
The programming interface for the thread package consists of 
several functions that are grouped into a few namespaces. A lot of 
functions have got a parameter/argument that specifies a 
subcommand at the first position.

How do you think about the 
following suggestion?
I would like to try an interface design like 
that:
Examples...
1. thread::mutex lock 
    instead of
    
thread::mutex::lock 

2. thread::cond::create
    instead 
of
    thread::cond create

3. tsv::array::names
    instead 
of
    tsv::array names

Does the increased use of 
namespace functions make a valuable difference in speed and 
maintenance?
Is it a step nearer to an object oriented TCL class 
library for thread programming?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-01-22 00:32

Message:
Logged In: NO 

I have nothing against that. It will however yield no speed  
imporvements. Ok, the maintenance might be simpler.   
The ideal OO-like approach would be:  
  
set mutex [thread::mutex new]  
$mutex lock  
  
But, this would defeat the byte-compiler and impose speed  
limits. Also, since the "$mutex" command will then be   
limited to single interpreter, you'd loose the transparency  
of the item (in this case the mutex) among threads, so it will  
even more complicate the matter. Therefore, this is the  
approach I've dropped from further considerations. 
 
Which leaves us with your proposed change. As I said, I see 
no real problems in that. 
 
Zoran 
  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=672050&group_id=10894