Add support for Object Literals #86
Labels
enhancement
Improves the implementation with something noteworthy
good first issue
Are you trying to have a good at SOMns? Start here!
language-design
Not everything is in the spec, sometimes, we need to decide what's best.
Object Literals are defined in the Newspeak spec sec. 5.1.10.
Depending on the context where they are defined, they either have the current activation (i.e. Truffle frame) as context, or
nil
. From that I derive that object literals can only be defined either on the module level or within a method.The proposed syntax is
objectLiteral = (identifier, keywordMsg opt) opt, classBody.
This means, we could have the following code:
For the implementation, beside the parser changes, there is at least one change needed:
SClass
is defined with final SObjectWithClass enclosingObject to represent the outer scope. This needs to be changed so that the outer scope also can be aMaterializedFrame
. This should be a straightforward change, there are only two things that depend on it: reading of the outer object which is either done with theouter
keyword for an outer send, or for an implicit send. This does likely not need any adaptation, beside potential casts, because, access to local variables, i.e., the sends to the current activation are not done as 'sends' but are directly done as local variable accesses. I am not entirely clear on whether there are any issues in the parser's lookup logic for determining whether it is a variable read or a message send, though. Currently, it first checks for local variables, and then does a send. That might be more involved with the additional nesting logic.The second thing that needs the enclosing object is the check whether a class is a value. That might be a bit more involved. Currently it should be simply returning false for activations, I presume. Except perhaps if they don't have locals. That gets more complicated if we actually start supporting lazy slots (promise slots, not sure what the spec term is) and immutable slots, but, we currently don't have that.
I am not sure what else interferes with it, there might be more.
The text was updated successfully, but these errors were encountered: