2015-12-04 20:29 GMT+01:00 Andrei Chis <chisvasileandrei@gmail.com>:
On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
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
Thanks eliot
Yes, we have this code too, I think, using the global var instead of a symbol happened by accident.
@andrei (and stefan?) can you check the GTDummyExamples methods and replace classes with symbol names.
After this is removed I will change the parser to notify about this.
I updated the pragmas to use symbols.
Thanks!
Cheers, Andrei
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
?
no idea.
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