On 2010-08-19, at 17:26, Rami Ojares wrote:
> 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.
I call these the representation and the implementation, but you are right, they
are both representations of an abstract notion, and there can be many
representations, e.g., a third representation of a trilean could be a
visual/graphic display of green/yellow/red light. So far we only allow string
representations and Javascript implementations.
> 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
>From the LZX point of view, we have an interface for <attribute> that
>understands `type`.
this.presentAttribute('again', 'trilean') => "maybe"
[You should not have to supply the type argument, but we don't yet fully record
attribute types at runtime. They are only there for types that are styleable
by CSS, because the runtime needs to convert a CSS string representation to the
appropriate implementation type.]
> 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.
Yes. The <type> protocol defines two methods, accept and present, which
convert from a string representation to the internal implementation value and
back. This is already defined for the existing 'built-in' types, and this is
how data-binding works. Datasets are string representations and when you
data-bind attributes, the type defines how the data representation is mapped
to/from the implementation values stored in the Javascript.
You are right that we need to provide some more Javascript support for working
with string representations. A lot of our current code just happens to work
because Javascript is pretty forgiving about comparing values of different
type. But one place where it really falls down (and which motivated all this
work, to make datamapping resonable) is:
false == "false" => false
I.e., when users would naively data-bind a boolean attribute and then specify
in XML that that attribute should be "false", they would get the surprising
result that Javascript considers "false" to be a truthy value, because it is a
non-empty string. The solution was to create the concept of
"PresentationTypes" that map between representation and implementation.
The question I am getting at here is whether literal values, specified in LZX,
in the `value` property of an <attribute> should be interpreted as Javascript
implementation values (as they are now) or if it would be more correct to
interpret them as LZX (string) representations. As Henry points out, we
already do this a little bit with the auto-quoting of string values. The
compiler also does some pre-processing on other literal values when it knows
the type, but the support is incomplete: there is no conversion at runtime for
non-literals.
We have totally fudged it for `fgcolor` and `bgcolor` by having their setters
heuristicate the value to a color: they will accept a number or a string in
any of the approved CSS formats. But if I create my own attribute of type
`color`, it will be a second-class citizen, because it will not have this
magical setter (unless I write my own). I think this difference shows that we
really need a more uniform approach. The fgcolor and bgcolor setters would not
need to be so smart if all attribute values were automatically converted
according to type.
> - 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
