octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #51377] Parse error for abstract methods


From: Piotr Held
Subject: [Octave-bug-tracker] [bug #51377] Parse error for abstract methods
Date: Thu, 17 Aug 2017 19:46:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Follow-up Comment #5, bug #51377 (project octave):

I wanted to write down somewhere our conversation from IRC and point to the
problems with my cset and how to solve parsing problem. For Octave it is
important to know if a method block has attribute Abstract. This is quite easy
if the declaration looks like this:


classdef mycls
  methods (Abstract)
    foo
  end
end


But that is not the only allowed syntax. Attributes can be called using
'Attrib_Name = value'. This 'value' can be be anything from 'true', 'false',
'private' to functions and metaclasses. Currently the interpreter does no
input validation on attributes at all and assigns their value during class
creation (using the information stored in a parse-tree). I have not done this
yet, but I was gonna propose to evaluate the value of an Attribute at
parse-time and assign it there, so that the parse tree holds that value.
Otherwise, if we evaluate the attribute value at parse-time to check what it
is, we will have to evaluate it again during class creation. What do you think
of this proposal?

Also does anyone have an idea how to solve the recursive attribute lookup
question? (Right now I just simply avoid evaluating '?' and 'metaclass' calls
when parsing attributes). My idea was to look at the call stack and see if the
caller is a __make_class_meta__ call, but I think that isn't all that great.

To give examples of what I'm talking about:


classdef child < parent
end

classdef parent
  methods (Access = ?child)
    function foo (self)
      1;
    end
  end
end


If we evaluate the value of Access at parse-time we create a recursive parse
lookup when invoking the constructor of either the parent or the chld (when we
create the child we need to parse it->to parse the child we need to parse the
parent->when parsing the parent we look at attribute Access and then we try to
get it's value->to get it's value we need to parse the child-> and so on). Any
suggestions?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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