octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accepting arbitrary strings as structure field names


From: John W. Eaton
Subject: Re: Accepting arbitrary strings as structure field names
Date: Fri, 10 Nov 2006 12:07:00 -0500

On  5-Nov-2006, Rafael Laboissiere wrote:

| * Rafael Laboissiere <address@hidden> [2006-11-05 12:42]:
| 
| > There are two problems with this patch, at least:
| > 
| > 1) Command completion.  When doing
| > 
| >    octave> var.[TAB]
| > 
| >    we get:
| > 
| >    octave> address@hidden
| > 
| >    which results in a syntax error.
| > 
| > 2) Saving/loading in text mode fails:
| > 
| >    octave> var.("@#$%") = 0;
| >    octave> save -text data var
| >    octave> load data
| >    error: load: bogus identifier address@hidden' found in file `'
| >    error: load: internal error loading struct elements
| >    error: load: trouble reading ascii file `data'
| >    error: load: reading file data
| > 
| > I am thinking about writing a patch for addressing both issues above.  I
| > would also introduce a built-in variable warn_arbitrary_string_in_field_name
| > (or whichever name).  Do the Octave maintainers think it is worth
| > implementing the idea?
| 
| Attached below is a trivial patch addressing both issues above (the built-in
| variable mentioned above is not implemented though).  It is actually rather
| a matter of removing than adding code.  The completion does now:
| 
|     octave> var.("@#$%") = 0;
|     octave> var.a = 1;     
|     octave> var.[TAB][TAB]
|     var.("@#$%")  var.a
| 
| Of course, this will not complete:
| 
|     octave> var.("@[TAB]
|     
| but at least the completion will not end up proposing syntactically
| erroneous code.

My only concern about this change is that we can no longer document
that struct.(field) is exactly equivalent to struct.field, except that
in the former case, the field name can be a variable.  Now we also
have to explain that there are no restrictions on the characters that
may appear in a dynamic field name, but for struct.field, the field
name is restricted to the set of valid symbol names
([_A-Za-z][A-Za-z0-9]*).  Are there any other potential problems?
Does save/load work if the field name contains embedded NUL
characters (I suspect not)?  What about other non-printing
characters.  Do they cause trouble?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]