Re: Extension candidates

>> language processors. Therefore, to think of a "reference" only as a
>> memory address is a very narrow approach that misses important cases
>> of "reference".
>
> I think you're missing the point. Generating plain old strings from nodes
> with a guarantee of being able to reverse the mapping will always leak
> resources of one sort or another, be it memory, disk space, file descriptors
> etc. Given that, I asked for a compelling use case for requiring this
> feature.


AFAIR Dr. Kay and I already described cases that need such references.

As for the "leaking resources", this requires a more exact definition.
I don't think that being able to access an XML file is a "leak" of
resources. Even in XSLT 1.0 there always has been such a "leak": the
document() function that provides us with such access to an XML file
given a corresponding URI and that guarantees it will have the same
result (XML document) on *any* evaluation during the transformation.
This *is* an example of a "reference" and in fact one possible
implementation of references is entirely through the document()
function and a URI resolver.

Dimitre



On Fri, Dec 12, 2008 at 11:06 AM, John Snelson <[email protected]> wrote:
> Dimitre Novatchev wrote:
>>
>> On Fri, Dec 12, 2008 at 8:37 AM, John Snelson <[email protected]>
>> wrote:
>>
>>>> Therefore, having a reference forever does not mean having the
>>>> referenced object alive forever -- no major problem here.
>>>
>>> That's not really true. The fact that nothing changes is an illusion that
>>> the language environment plays on the program by carefully managing it's
>>> access to the outside world (disk, network, etc.). It's entirely possible
>>> that an XML file on disk could change during the time a program is
>>> running.
>>
>> We have to draw the line somewhere: There could be an earthquake in SF
>> or an ice storm in NE, or even a meteorite could collide with the
>> Earth...
>>
>> I think it is quite off-topic here to speak even about transactions.
>>
>> It is totally up to an XSLT processor or its optimizer whether to keep
>> something in memory, or to discard it and reassemble it later on
>> as-needed basis. AFAIK, this is already the case with existing
>> language processors. Therefore, to think of a "reference" only as a
>> memory address is a very narrow approach that misses important cases
>> of "reference".
>
> I think you're missing the point. Generating plain old strings from nodes
> with a guarantee of being able to reverse the mapping will always leak
> resources of one sort or another, be it memory, disk space, file descriptors
> etc. Given that, I asked for a compelling use case for requiring this
> feature.
>
> John
>
> --
> John Snelson, Oracle Corporation            http://snelson.org.uk/john
> Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
> XQilla:                                  http://xqilla.sourceforge.net
>



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play