Re: [OEP] Classes as Values - Abstract

>> Neither of us feel that strongly about having this in the abstract,
>> however we can't figure out why you think the document doesn't do
>> this.  It presents one use case in detail, under the section titled
>> "USE CASE", which is then addressed in all the examples, and in
>> addition there is a section "Other use case scenarios" which mentions
>> other possible use cases, all in the context of motivating why you are
>> doing this.
>>
>> If you agree, maybe a slight re-wording would be acceptable, but if
>> this will generate prolonged debate it's not worth it and you can
>> remove it.
>
> Hmm... I still feel that the note doesn't try to motivate the use of
> classes as values. In fact, it almost does the opposite: it shows how
> you can represent the same (or very similar) information _without_
> using classes as values.
>
> [MFU] Ah, Now I see. Yes, strictly speaking you are right. The wording 
> needs to changed to reflect the following (which I think we an agree 
> on, never mind the words). What this note is REALLY about is what to 
> do when you want to model something, for which representing classes as 
> values is the most obvious, direct and natural thing to do. You can 
> either represent classes as values directly, (case 1), or you can do 
> various other things. Insofar as option one is obvious and 
> straightforward, the real purpose of the note is, as you say, how to 
> get the effect you want by NOT representing classes [directly] as 
> values.
>
> If have any ideas on how to reword this, have a go, or else I will be 
> happy to. Just give me the latest version to start with.
> ---

Mike, you are welcome to have a go at it. Before you do there, read the 
current version of the abstract since it has been reworded after all 
the discussions. I think it says something close to that already.

Natasha