Unit values

[Adde]

Brian Rice wrote:

>
> On Apr 27, 2005, at 3:01 PM, Adde wrote:
>
>> Brian Rice wrote:
>>
>>> On Apr 27, 2005, at 2:02 PM, Adde wrote:
>>>
>>>> Brian Rice wrote:
>>>>
>>>>> I think the attention you two have given this library has reached 
>>>>> a threshhold. If you read the source, you'll see that I just 
>>>>> ported it from Smalltalk-80 and didn't care too much about it.
>>>>>
>>>>> Right now, you two care more about it than I do. So put your 
>>>>> fingers where your mouth is, and code up these changes yourself 
>>>>> and use darcs send so I can apply them.
>>>>>
>>>>> Patches speak louder than words! :)
>>>>>
>>>>> On Apr 27, 2005, at 7:41 AM, David Hopwood wrote:
>>>>>
>>>>>> Suggestion: merge the UnitValue and Unit types, by having a unit 
>>>>>> behave
>>>>>> as 1 of that unit, i.e. px = 1*px.
>>>>>>
>>>>>> Then only multiplication is needed to form a UnitValue, e.g. 42*px.
>>>>>> Similarly examples like "(72*px) / in" would work automatically. 
>>>>>> This
>>>>>> design also allows derived units and conversion factors to be 
>>>>>> expressed
>>>>>> more simply.
>>>>>
>>>> I'm fine with implementing the changes myself if and when I feel I 
>>>> understand the problem well enough.
>>>> One thing I'm wondering that has nothing to do with the Units 
>>>> library is if there is any way to dispatch on a slot of an object.
>>>> Something like this maybe:
>>>>
>>>> uv unit@(Pixel traits) printOn: p@(SVG Printer traits) [
>>>>  uv value printOn: p.
>>>>  uv unit printOn: p.
>>>> ].
>>>>
>>>> And if that isn't possible, do you think it'd be a good idea to add 
>>>> a slot to BaseUnit that contains the base for it's values so that 
>>>> you can dispatch on that instead? It wouldn't mean any changes to 
>>>> the code using the library since BaseUnit could init the slot 
>>>> itself. Then you cold do things like this:
>>>>
>>>> uv@(Pixel baseValue traits) printOn: p@(SVG Printer traits) [
>>>>  uv value printOn: p.
>>>>  uv unit printOn: p.
>>>> ].
>>>
>>>
>>> Dispatching on slot-values is basically dynamic pattern-matching. 
>>> This is problematic mostly for performance reasons, but also your 
>>> syntax and methodology for this definition is unsound. Slate is one 
>>> step away from this level of semantics for a good reason...
>>>
>>> What you're failing to grasp is that what follows the @ is just 
>>> another Slate expression which happens to annotate the argument name 
>>> you've specified, so "Pixel baseValue traits" will get you the 
>>> traits object of whatever is returned by sending baseValue to Pixel, 
>>> not by sending baseValue to uv. Furthermore, uv is the argument of 
>>> the message, not its baseValue. The fact that Slate has no special 
>>> syntax here is a hard limit to what we can do this way. You just 
>>> can't dispatch on something that's not an argument in Slate. As far 
>>> as I can tell, you have to choose between simple, flexible syntax 
>>> (Slate) and being able to do pattern-match-y things (Cecil, Haskell, 
>>> etc.) by using a baroque syntax.
>>>
>>> Maybe Lee has some ideas on how to admit pattern-matching-like 
>>> semantics to Slate, since he's given it a little thought, but don't 
>>> count on this any time soon (i.e. before we bootstrap into a much 
>>> less concrete syntax, and even then don't expect us to go the route 
>>> of languages "with declarations" like Haskell or Java).
>>
>> I think I confused you a bit by mentioning dispatching on slots, 
>> forget I mentioned that, it was just a crazy idea ;)
>> 'Pixel baseValue traits' is exactly the object i want, if 'uv' is 
>> cloned from 'Pixel baseValue' then it's a Pixel value.
>> Load the following:
>>
>> Ensurenamespace: #Test.
>>
>> Test addPrototype: #UnitValue derivedFrom: {Cloneable}.
>> Test UnitValue addSlot: #unit.
>> Test UnitValue addSlot: #value.
>>
>> Test addPrototype: #BaseUnit derivedFrom: {Cloneable}.
>> Test BaseUnit addSlot: #name.
>> Test BaseUnit addSlot: #abbrev.
>> Test BaseUnit addSlot: #baseValue.
>>
>> bu@(Test BaseUnit) name: n abbrev: a [ |u|
>>  u: Test BaseUnit clone `>> [name: n. abbrev: a.].
>>  u baseValue: (Test UnitValue clone `>> [unit: u.]).
>>  u
>> ].
>>
>> Test addImmutableSlot: #Pixel valued: (Test BaseUnit name: 'pixel' 
>> abbrev: 'px').
>>
>> n@(Number traits) px [
>>  Test Pixel baseValue clone `>> [value: n.]
>> ].
>>
>> uv@(Test Pixel baseValue traits) toXML [
>>  'This is printed because uv is a Pixel value, ie. cloned from Pixel 
>> baseValue'
>> ].
>>
>> and then execute this:
>> (1 px) toXML.
>>
>> Instead of cloning UnitValue when creating new Pixel Values you only 
>> have to make sure that you clone Pixel baseValue instead.
>
>
> What the %@#! is this? What's the intent? This doesn't fit into any 
> way I know how to use Slate reasonably, and is liable to just confuse 
> the reader/caller. Stop futzing with this library that is already easy 
> to use and expressive, and work on some useful code! If you do reply, 
> don't just paste code at me and expect me to get it - take time to 
> write a few paragraphs on the design issues, and then don't send it 
> for another several hours, after you read it again and make sure it's 
> clear.
>
> Don't expect a reply from me for another 12 hours at least, because I 
> need to focus on deeper more practical Slate issues, and am 
> disconnecting from email/etc. usage so that this weird stuff doesn't 
> float about in my head.
>
> -- 
> Brian T. Rice
> LOGOS Research and Development
> http://tunes.org/~water/
>
It's a minimal example of how you'd implement the solution I proposed.
I guess I was under the mistaken impression that being able to override 
behaviour (like printing) for values of specific units was a reasonable 
way to use Slate.

All i did was make sure all values of a specific Unit had a common 
parent object, so I could use that common parent object to override 
behaviour for all values of that unit. I tried to explain but i felt 
that I wasn't getting through, since English is my second language I 
thought that maybe I could explain it better to you if you saw the 
results yourself.

I'm a bit confused about this, one minute you encourage me to make the 
changes myself and submit patches and the next you ask me to stop 
futzing with the library that is supposedly good enough as it is. Could 
you then please explain how I would override printOn: for values of a 
specific Unit cause i sure couldn't find a way.

If the level of this list is that high (that you have to review all 
messages for several hours before posting) then that wasn't clearly 
stated anywhere so I had no chance of knowing that. I'll take my chances 
with this mail, though.

Don't expect anyone to be interested in helping out if you treat them 
like dirt.
Happy focusing!

/Adde