Issue #5722 has been updated by Marten Lohstroh.
Assignee changed from Christopher Brooks to Marten Lohstroh
% Done changed from 0 to 100
Arbitrary string are allowed as record labels as of rev. 66121; the expression
language is adapted to make this possible. The change is backward compatible
because strings that qualify as valid Java identifiers are still allowed to be
used without quoting them e.g., {a=1, b=2} is still accepted, but now {"a"=1,
"b "=2} is accepted too. The only thing which should be mentioned that does not
extend to the use of arbitrary strings as record labels, is the dot notation to
retrieve fields e.g., {a=1,b=2}.a works, but {"a"=1, "b "=2}."b " does not
work. This is not a problem because the dot notation is only a shorthand for
the get() method, so {"a"=1, "b "=2}.get("b ") works fine. Quotes within quotes
must be escaped e.g., {a=1, "b "=2, "_c\"!"=3}.get("_c\"!") yields the value 3.
One additional problem that has been solved is the following: because arbitrary
strings include the use of periods, and periods are not allowed in port names
(because it makes their identifier ambiguous), therefore RecordAssembler and
RecordDisassembler now use the display name of ports (which has no formatting
restrictions) to construct their types. Note that the display name is used
instead of name only if it is actually defined.
----------------------------------------
Bug #5722: Check for problems with sanitized RecordToken labels
https://projects.ecoinformatics.org/ecoinfo/issues/5722#change-20387
* Author: Derik Barseghian
* Status: New
* Priority: Normal
* Assignee: Marten Lohstroh
* Category: general
* Target version: 2.5.0
* Bugzilla-Id: 5722
----------------------------------------
Filing a bug so this doesn't get forgotten - I said I'd try to look into this
ptII change, r64639:
-------
Sanitize RecordToken or OrderedRecordToken labels, which means that characters
like spaces will be converted to underscores. This is necessary so that the
string representations of RecordTokens can be reparsed by the expression
language. The alternative of modifying the expression language to allow
strings as labels causes conflicts in the parser.
-------
I worry this change is going to cause problems...anything that expects (e.g.
checks equivalence) the data in a label to come out of a RecordToken as it went
in will seemingly have a problem. It also sounds like a lossy translation.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
https://projects.ecoinformatics.org/ecoinfo/my/account
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
