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: Rafael Laboissiere
Subject: Re: Accepting arbitrary strings as structure field names
Date: Sun, 5 Nov 2006 12:42:58 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

* Etienne Grossmann <address@hidden> [2006-11-04 22:19]:

> On Sat, Nov 04, 2006 at 09:40:38PM -0500, Bill Denney wrote:
> # Rafael Laboissiere wrote:
> # >Would it be acceptable to remove the restriction of structure field names
> # >being valid_identifier?  The benefit of this change is that Octave will 
> # >have
> # >hash arrays for free, allowing code like this:
> # >
> # >    var.("@#$%") = 0;
> # >  
> # I'm guessing that this would be pretty hard to do.  Is there a reason 
> 
> would it? With a two-line patch (a check removal, more precisely, see
> below), I can do:
> 
> octave:5>  var.("@#$%") = 0;
> octave:6> var
> var =
> {
>   @#$% = 0
> }

Thanks, I have already tried the same patch here (hence the mention to
valid_identifier in my original post).

> Disclaimer: I didn't check for potential trouble brought by the patch.

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?

-- 
Rafael



reply via email to

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