Pragma syntax

Andrew Tween amtween at hotmail.com
Sun Aug 20 11:17:26 UTC 2006


Hi Lukas,
----- Original Message ----- 
From: "Lukas Renggli" <renggli at gmail.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, August 19, 2006 7:28 PM
Subject: Re: Re: Re: Re: Re: Pragma syntax


> > > Note 1: I see the pragma selector as a message that can be sent to an
> > > object to configure it somehow, binary selectors usually have a
> > > slightly different meaning.
> >
> > I don't get that.
> > Which object is #primitive: sent to, and how does it configure it?
>
> No problem, you are not the only one :-(

:)

>
> After the compilation the message #primitive: with the given arguments
> is performed on the parser. This is then changing the current method
> to be a primitive. It works the same for #primitive:module: where
> there is just slightly different code executed. Have a look at the
> implementors of those two messages in a 3.9 image.

Ok. Yes, I see it now. thanks.

>
> Now, how do I know what pragmas I should perform on the parser and
> what pragmas not? It is hardcoded right now, but that could be solved
> nicely as I suggested in my original mail that caused all this
> discussion. So the parser-class could then declare some of its methods
> (namely #primitive: and #primitive:module:, and also #apicall:module:
> and #cdecl:module: if the FFI people would accept) as methods to be
> called after the compilation. Very extensible. Very modular. Very much
> oop. And no patching.

Yes. But, there are some potential drawbacks...
    1. I cannot write an extension which uses a name that is already in use by
the Parser.
        e.g. #notify: , #parse:class: etc.

    2. It might be a dangerous thing to use one of the method names defined in
Parser's superclasses. e.g. #error:

    3. No keyword methods can safely be added to the Parser in the future. The
new method's name might already be in use by an extension. A change to the
parser's interface (i.e. the selectors it implements/understands) could result
in an extension, and/or, the parser breaking.

Please see my post in the 'Re: An alternative FFI/Parser proposal' thread for a
possible alternative arrangement. What do you think?

Cheers,
Andy

..snip...




More information about the Squeak-dev mailing list