A type is a set of values (in practice a finite set of values.
A single value can have more than one representation.
In case of trilean one could say that it consists of 3 values whose
primary representations are yes, no and maybe.
Those values could also have secondary representations 0, 1 and 2.
The difficult part is of course how to make those representations
(literals) work inside javascript.
because javascript does not "understand" them eg.
this.again == yes would only work if yes would be a reserved word like
true and false.
As you suggested one could use the type to somehow generate the literal
this.again == lz.trilean.yes
But what would be the default representation of a value.
If it would be a number accroding to javascript then the literal would
be a number.
Debug.debug("%w", this.again) --> 2
And if one would like a different literal representation one could once
again use the type for that
Debug.debug("%w", lz.trilean.literalX(this.again)) --> maybe
Since everything must have a string representation that should be the
default representation.
Of course for natively supported types like number and boolean there
would be an exception.
But the only difference is that the literal does not have quotes around it.
this.num == 3
this.str == "3"
this.tril = "maybe"
The quotes make the literals independent of the reserved words of the
language.
this.tril = "maybe" would need to be transformed to
this.tril = <type_of_tril_variable>.parseValueFromLiteral("maybe")
So something similar what happens in javascript in expressions like 1 == "1"
So a type would have two methods
myType fromLiteral(string) (parse)
string toLiteral(myType) (format)
I quess that is the function oif the accept method you mentioned.
- rami
On 19.8.2010 23:57, Henry Minsky wrote:
Yeah we already have the value being interpreted implicitly with the
builtin types,so
that string type doesn't need need be quoted, etc
<attribute type="string" name="foo" value="bar"/>
so it seems natural to make value use the 'accept' mechanism
On Thu, Aug 19, 2010 at 4:46 PM, P T Withington <[email protected]
<mailto:[email protected]>> wrote:
Push comes to shove in this case:
<attribute name="whatever" type="color" style="color" value="black" />
Here we have an attribute that is styleable using CSS, which may
specify a value in a number of ways: named color, #format, rgb(),
hsv(), etc. It's pretty clear (to me at least) that the
fallback/default specified in `value` should be in that same
space. I should _not_ have to say `value="0"` to specify a
default color of black.
Therefore, I propose, at least for attributes that have a `style`
property, the `value` property is assigned to the attribute using
the specified type's `accept` method.
On 2010-08-11, at 11:44, P T Withington wrote:
> Here's an important question that needs answering, before we can
really go anywhere with this:
>
> If I define a new type, say `trilean`, that is stored as 0, 1,
or 2, but is meant to represent a tri-state yes/no/maybe button in
a form, when I write:
>
> <attribute name="again" type="trilean" value="???" />
>
> What is the expectation about the `value` field?
>
> Currently, for all the built-in presentation types, (except for
color), `value` is interpreted as the corresponding Javascript
type, but maybe this is just luck because the Javascript type and
the LZX type look similar enough no one noticed. E.g., I say:
>
> <attribute name="ok" type="boolean" value="false" />
>
> I use the Javascript value `false`, not the representation
`"false"` (which is how a boolean would be stored in a dataset).
>
> If we extend that model, for my trilean, I would have to write:
>
> <attribute name="again" type="trilean" value="2" />
>
> which is not really helpful. I would have to remember wether
`2` corresponds to "yes", "no", or "maybe". I would much rather
write:
>
> <attribute name="again" type="trilean" value="maybe" />
>
> Is this what people expect? I'm not sure how we could reconcile
the current built-in types with this new distinction. It makes me
think that we need a new property of attribute that is the
"representation type"?
>
> <attribute name="again" type="trilean" ???="maybe" />
>
> What's a good name for that?
>
> [that leaves open the issue of how I write Javascript code to
manipulate `this.again` -- there I need to know the corresponding
values. Probably I want to be able to say:
>
> if (this.again == lz.trilean.yes) ...
>
> or something.]
>
>
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
