[kepler-dev] [Bug 5722] Check for problems with sanitized RecordToken labels

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5722

Marten Lohstroh <marten at eecs.berkeley.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marten at eecs.berkeley.edu

--- Comment #13 from Marten Lohstroh <marten at eecs.berkeley.edu> ---
If certain strings are unacceptable as labels because the parser cannot deal
with them, then the only right behavior for records is to reject such labels
(as was established by changeset 64633). The problem is that actors like
RecordDisassembler and RecordAssembler use a number of complex type constraints
that tie port names to labels in RecordTypes. Bluntly renaming labels results
in undesired behavior and unexpected typing problems. Because the the
sanitation mapping is not invertible, the original port names can no longer
function as proper identifiers. E.g., what kind of record should a
RecordAssembler with two inputs "a b" and "a_b" produce? And how can
RecordDisassembler ensure that its input record has two distinct fields that
correspond two its two outputs "c d" and "c_d"? Errors like these would be
trapped by RecordType as it requires labels to be unique, but the resulting
errors are not very friendly, and the solution as a whole is not very elegant.

If we want to allow record labels that are equally expressive as port names,
the expression language needs to be adapted. This is a task that requires some
careful thought. I don't have time to look into this right now, but I will look
do so by the end of February and come up with a proposal / candidate
implementation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20130123/8b1d91b1/attachment.html>