Hi Nicolai, On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
GTDummyExamples class d: anInteger <gtExample> <label: 'Dummy #d:, depends #c:'> <description: 'should raise an exception as the argument is not anInteger'> <depends: #c:> <raises: Literal constant expected -> MessageNotUnderstood>
^ 1 + anInteger
The old Parser complains about the class name "MessageNotUnderstood" used as a pragma argument without being a string or symbol
Opal does not complain
Is Opals behavior intended ?
IMO no. The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g. addressField <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> ^self primitiveFailed instead of addressField <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> ^self primitiveFailed The issues are class reference, class redefinition, class removal etc. I guess we could extend the pragma syntax to allow class references but there's a lot of impact. I would prefer if we keep things restricted. There's nothing to stop one using a symbol and mapping it to a class name, e.g. GTDummyExamples class d: anInteger <gtExample> <label: 'Dummy #d:, depends #c:'> <description: 'should raise an exception as the argument is not anInteger'> <depends: #c:> <raises: #MessageNotUnderstood> ^ 1 + anInteger Also, I *hate* this style of pragma. Why not GTDummyExamples class d: anInteger <gtExampleLabel: 'Dummy #d:, depends #c:' description: 'should raise an exception as the argument is not anInteger' depends: #c: raises: #MessageNotUnderstood> ^ 1 + anInteger ? That's how the system is designed to be used. Then the message can be implemented by a builder which performs the selector from a visitor.
From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770
Cascading message sends to super.
Compiler refuses to compile super initialize; setListProperties
It looks like Opal would compile this to
super initialize. super setListProperties.
Intended ? Do we want to keep it?
NBNativeCodeGen parseOptions: optionsArray uses association symbol -> block instead of block -> block for caseOf arguments. The old parser does not accept this.
-- _,,,^..^,,,_ best, Eliot