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

[Andrew Janke]

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

I don't have answers to all this, but here's some thoughts.

> 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? 

I'm going to defer to your thoughts on this: since I'm an Octave newbie, I'm
hesitant to propose any breaking changes to current behavior.

If you prioritize full Matlab compatibility, then yes, I think we probably
need to do the four things in your list instead.

> Are you saying that the rules you list in comment #19 should only apply to
index sequences that begin with '.' operators?

No - a plain identifier, or an index sequence that begins with (), should be
considered a degenerate case of this with 0 .-indexes, and the initial
identifier should be checked to see if it names a Java class in the
root/default package. Similar to how it could be an Octave classdef name, for
calling a constructor.

> Do we ever need to consider more than the current index? 

Effectively, yes. Java package names are flat, not hierarchical. That is, if
there is a Java package "a.b.c", that does not imply the existence of packages
"a" or "a.b". And if they do exist, there is no relationship between them. We
could construct those "implied" packages in ov-java, but the JVM won't handle
it for us.

> 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 think you're right. The way Matlab does it, as soon as a classdef object
with a user-defined subsref() is recognized, then all of the indexing
expressions in the entire rest of the chain are passed in to its subsref()
method in a single call, and it can do whatever it wants with the entire
chain.

>  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? 

I think you need to be greedy, at least with () indexes. Otherwise, for a
simple "fcn(ix)", how are you going to differentiate between calling fcn with
the argument ix versus calling fcn with zero arguments and indexing in to the
result? You can always force the other behavior with "(fcn)(ix)".

There's another complication with fcn.field. Classdef names are also
constructor names, so they're functions, too. If there is a class named "fcn",
should "fcn.field" access a Constant property of the class, or call the
zero-arg constructor, and index into the new object? Constant properties can
be accessed through classdef instances, so it would still "work", but it seems
undesirable to have the instance creation as a side effect.

    _______________________________________________________

Reply to this item at:

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

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