[Octave-bug-tracker] [bug #48428] Support for java.lang.XXX syntax

[John W. Eaton]

Follow-up Comment #20, bug #48428 (project octave):

Given that we currently allow


fcn.field


to call the function fcn and then perform structure field indexing on the
result, are you proposing that we continue to allow that, even if there is a
+fcn package directory in the load path?

Or should we be checking whether

0 fcn is a variable (could hold a classdef or java object)
0 fcn names a classdef(?) or java object for referencing static members (I
don't even know whether that's how these things work)
0 fcn names a package directory, in which case it limits the scope of
additional symbols in the expression
0 fcn is a regular function to call.  At this point, if we want to be
compatible with Matlab, we don't allow any further indexing except '(...)' for
function call arguments.

Are you saying that the rules you list in comment #19 should only apply to
index sequences that begin with '.' operators?  Do we ever need to consider
more than the current index?

I think we could do a better job with the 's(i).f' form of structure array
indexing.  Currently, I think we are splitting this indexing operation into
's(i)' and then applying the '.f' field selection to the result.  Instead, I
think we need to recognize '()' followed by '.' and pass both to the
octave_struct subsref method.  Otherwise, we can't do the right thing for a
user-defined subsref function for structs.  I know we don't handle that case
now, but it should at least be possible and as far as I can tell, the current
code doesn't allow it to work properly.

I find the visit_index_expression function to be way too complicated as it is.
 Maybe eliminating some of the Octave extensions to Matlab indexing would help
with that.  Maybe we won't have to eliminate them all.  But would doing away
with fcn.field really be that bad, especially if we still allowed
fcn(args).field?  OTOH, maybe we dan't have that either, because it looks like
a struct array indexing operation.

What about a function call that produces a struct array?  If we allow
fcn(args).field.  Calling fcn with no args and indexing teh resulting struct
with '(args).field' makes sense, but so does calling fcn(args) and then
indexing the result.  Should the expression always be 'greedy' and grab as
many indices as can possibly make sense?

Ugh.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48428>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/