Prevent cloning of clones

[Brian Rice]

On Apr 26, 2005, at 1:37 PM, Adde wrote:

> Brian Rice wrote:
>>> I plan on changing the toXML methods into printOn: s@(XMLStream) to 
>>> match the rest of the environment better.
>>
>> Cool. You can also do "XML WriteStream" or "XML Document WriteStream" 
>> or also use "nextPut:" and override per type.
> I'll look into it, though I'm sure I'll have to pester you some more 
> about it before I get it to work ;)
> Are there any examples in the library that I can look at?

On second thought, XML WriteStream would mean something else. If you 
look at lib/stream.slate and lib/iterator.slate, you'll see the basic 
stream types and the ones defined "as attributes of" various collection 
types (this is done by, e.g., Bag traits addPrototype: #WriteStream... 
and then someBag WriteStream or someBag writer). These are used to 
build up those structures, and this could be done with XML but it would 
be a different idea.

So basically I'd suggest an "XML Printer" which you can override 
printOn: for, basically your original idea just with the name tweaked 
to be a little clearer.

>>> I feel a bit unsure about the method on UnitValue traits, it feels 
>>> like I should only provide toXML for my own UnitValues, something 
>>> like this:
>>>
>>> SVG addPrototype: #Unit derivedFrom: {BaseUnit}.
>>> SVG Unit addImmutableSlot: #Pixel valued: (SVG Unit name: 'pixel' 
>>> abbrev: 'px').
>>> SVG addPrototype: #UnitValue derivedFrom: {UnitValue}.
>>>
>>> uv@(UnitValue traits) unit: u@(SVG Unit traits) value: v [
>>>  SVG UnitValue clone `>> [unit: u. value: v.]
>>> ].
>>>
>>> uv@(SVG UnitValue traits) toXML [
>>>  (uv value toXML) ; (uv unit abbrev toXML)
>>> ].
>>>
>>> At least that works as it should, "(1 px) toXML" works and "(1 kg) 
>>> toXML" gives an error.
>>
>> I don't think this is worthwhile; my recommendation is just to shift 
>> from toXML to the nextPut: overriding and deal with it then. You're 
>> basically programming over-defensively, since lengths may also count 
>> as SVG units.
>>
>> I should mention one issue, though: pixels are not specific to SVG; 
>> they're specific to the raster display type. Try to just keep it as 
>> "yet another unit" which will be in the units namespace, and not 
>> hardcode it as belonging to SVG. I say this because SVG is 
>> conceptually a particular rendering backend for the UI framework (see 
>> src/ui/) and as such I will want to have it not duplicate any 
>> structures.
>>
> It's highly likely that this is just me programming over-defensively. 
> I've spent a considerable part of my life trying to please C++.
> But, I feel that the only Units that should be used with toXML are 
> Units for which someone has specified an XML representation 
> (overridden toXML). Lengths counts as SVG units the second someone 
> specifies how a Length should be formatted in in an SVG Document.
> This feels like a problem that's bound to come up again, that you 
> wan't to add special formatting to specific kinds of Units (instead of 
> adding it to BaseUnit).
> I fully agree that the Pixel unit probably belongs in some kind of 
> Graphics namespace, though.

Fair enough. I can add Length/other-dimension subtypings for the 
various kinds of units for dispatch hooks.

On a related note, the with: message is supposed to work with arbitrary 
objects (e.g. "4 with: lobby" should turn into "4 lobbies"), and 
doesn't, so I'll fix that while my mind is on it as well.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/