Prevent cloning of clones

[Brian Rice]

On Apr 26, 2005, at 11:50 AM, Adde wrote:

> Thanks! I was just trying to understand when and how to limit further 
> cloning.
> Following your suggestions i came up with the following:
>
> SVG ensureDelegatedNamespace: #Units.
> SVG Units addImmutableSlot: #Pixel valued: (BaseUnit name: 'pixel' 
> abbrev: 'px').
>
> n@(Number traits) px [
>  n with: px
> ].
>
> uv@(UnitValue traits) toXML [
>  (uv value toXML) ; (uv unit abbrev toXML)
> ].
>
> s@(String traits) toXML [
> s
> ].
>
> n@(Number traits) toXML [
>  n as: String
> ].

Interesting.

> I added the px method to Number traits to be able to say: 1 px instead 
> of 1 with: px, don't know if that's a good idea but it certanly makes 
> it easier to use. The other methods are just placeholder for 
> XML-specific formatting.

The "px" message idea has occurred to me before, and I think what I'll 
do is have the BaseUnit creation method name:abbrev: create the method 
for you so you don't have to do it. How does that sound? :)

> 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 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.

> I have to say the language feels good so far, it strikes a fine 
> balance between the beauty of Smalltalk and the raw power of Lisp.

Cool, thanks!

> Brian Rice wrote:
>
>> On Apr 25, 2005, at 1:43 PM, Brian Rice wrote:
>>
>>> I strongly suggest that you just forget about this issue and don't 
>>> worry about the safety factor for now. Focus on the real design 
>>> issues first; your code is a mess and is not re-using the very 
>>> useful library I mentioned above. Try this instead:
>>>
>>> load: 'src/lib/dimensioned.slate'.
>>> SVG addImmutableSlot: #Pixel valued: (BaseUnit name: 'pixel' abbrev: 
>>> 'px').
>>>
>>> Doesn't that look better? It also can be used for actual algebraic 
>>> operations, e.g.:
>>>
>>> Slate> BaseUnit name: 'pixel' abbrev: 'px'.
>>> px
>>> Slate> 4 with: pixel.
>>> 4_px
>>> Slate> it * 5.
>>> 20_px
>>> Slate> it / (1 with: in).
>>> 20_px/in
>>
>> And if you define:
>>
>> x@(UnitValue traits) / y@(Unit traits)
>> [x / (1 with: y)].
>>
>> Then "(72 with: px) / in" works. I'll add that now to the main source 
>> tree.
>>
>>> The underscores are not really suitable for output into XML, but you 
>>> can easily do something different there, or we could fix the 
>>> print-out or provide some other means. In any case, you have 
>>> multi-dispatch and can handle the case specifically in any output 
>>> method.
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/