Hi Andrei, > On Dec 4, 2015, at 11:29 AM, Andrei Chis <chisvasileand...@gmail.com> wrote: > > > >> On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >> >> 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.mira...@gmail.com>: >>> Hi Nicolai, >>> >>>> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaih...@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.
They should be instances of Message, and the Message should hold onto the selector symbol and the argument. There should also be a Pragma class with an api that supports access. I'll gather up the relevant Squeak code (including tests) as a guide. Ok? > > 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 >
