From: Frédéric B. <fre...@fr...> - 2012-08-28 12:33:40
|
Le 28/08/2012 11:36, Donal K. Fellows a écrit : > On 28/08/2012 08:44, Frédéric Bonnet wrote: >> Well the idea was to make use of the length field as long as the bytes >> field is NULL (i.e. the string rep is invalid), as combining the >> starting index and the length gives you the exact substring range. But >> once the string rep is updated (e.g. for output or type conversion), the >> "substring" internal rep is no longer needed anyway and can be >> discarded, and the length field recovers its usual meaning. Think of it >> as a lazy [string range]. >> >> After a quick look to the code I think this should work, because the >> length field is never used when the bytes field is NULL, simply because >> the predicate for an invalid string rep is to check the bytes field >> against NULL. This means that the length field is "available" for >> objects without a string rep (for the good reason that it is simply >> meaningless). Of course this needs to be double-checked, but I don't >> think there is much risk there, as the length field is simply >> meaningless for objects without a string rep, so why would the core >> fiddle with it? > > I don't think anyone else has tried to do this sort of thing, so you'll > probably get away with it. You're planning to mutate the object type > when someone does a Tcl_GetStringFromObj() on the sublist object (i.e., > when the updateStringProc is called)? Correction: the idea is to implement *substrings*. *Sublists* are a quite different topic that need significant core overhaul, and using the length field to this purpose would be much more than a hijack... Regarding substrings, yes, the core idea is for e.g. [string range] to return a Tcl_Obj-based SubstringObj instead of a new string object, and possibly extract the actual substring later when its string rep is generated, resetting the object type so that the SubstringObj mutates to a regular string obj in the process. I don't think this violates any contract as it still respects the interface and the EIAS principle, but feel free to correct me. |