Re: [TCLCORE] CFV: TIP #696

[<apn...@ya...>]

Reminder - less than 48 hours remain before the voting period ends for #696.

-----Original Message-----
From: Rolf Ade <tcl...@po...> 
Sent: Tuesday, June 11, 2024 4:30 AM
To: tcl...@li...
Subject: Re: [TCLCORE] CFV: TIP #696


apnmbx-public--- via Tcl-Core writes:
> I have updated TIP 696 to reserve the code range [5 – 0x3fffffff] for packages/applications. Rationale is in the discussion section.
>
> Folks who have already voted, please resend if you change your vote else I’ll assume your original vote stands.
>
> Vote ends June 19, 2024 at 8am UTC.

TIP 696: Yes.

That thing is fine now; other ideas in this area are out of scope of
this TIP.

rolf

>
>  
>
> From: apnmbx-public--- via Tcl-Core <tcl...@pu...> 
> Sent: Friday, June 7, 2024 8:33 PM
> To: tcl...@pu...
> Subject: Re: [TCLCORE] CFV: TIP #696
>
>  
>
> Conflicts between user defined codes, like user defined namespaces,
> are unfortunately not tractable. A registry type system is not
> workable in practice – at least one was proposed many moons ago
> (https://www.nist.gov/publications/managing-tcls-namespaces-collaboratively)
> – but difficult to publicise and have people follow it. Best to choose
> a code at random if it is not private.
>
>  
>
> Not quite sure what you mean by exception handling. Return codes are a mechanism between C level calls as well.
>
>  
>
> /Ashok
>
>  
>
> From: Gustaf Neumann <neu...@pu... <mailto:neu...@pu...> > 
> Sent: Friday, June 7, 2024 11:59 AM
> To: tcl...@pu... <mailto:tcl...@pu...> 
> Subject: Re: [TCLCORE] CFV: TIP #696
>
>  
>
> On 06.06.24 23:05, Rolf Ade wrote: 
>
> I was too dense; sorry. You are right that in general the standard
> return codes ok, error, return, break and continue can be specified as
> symbols.
>
>  
>
> Has someone considered interactions between user-defined return codes?
> One could introduce a "registry" for return-codes to guarantee that
> there is no clash. Application could use e.g. a package specific name
> and get via this a fresh or already allocated value. This would reduce
> the chance of clashes. For NaviServer this is not an issue, since the
> NaviServer return codes are used only internally using its own type
> Ns_ReturnCode. Application specific error handling is performed via
> try + application specific error codes. Shouldn't exception handling
> anyhow be the recommended way for such kinds of problems on the Tcl
> level?
>
> all the best -g 
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core