An alternative FFI/Parser proposal

>> It seems to me (I may be wrong) that in Tweak event clause are  
>> syntactic sugar for more verbose forms as andreas showed in a  
>> previous email.
>> This means that they can then contains instance variable and in  
>> such as case this is not anymore literal only.
>
> No. They they contain *names* of variables, not variables themselves.

So this means that during the compilation of the method you map the  
name to iv?

>
>> This is even a point to fix before we could adopt sophie (modulo  
>> that what I said is correct).
>
> Why and what would need fixing?

Ok I was wrong even better. :)

>> this is somehow related to that issue I do not like in Tweak the  
>> fact that instance variable are defined using color
>
> That is incorrect. Variables are not defined using color, they are  
> displayed using color - not unlike any other syntax highlighting  
> scheme. In fact, you can change the color if you like (right click  
> to get the context menu and choose your color from the color submenu).

I was thinking about what could be a textual representation and a way  
to integrate in the class creation interface (basically an entry  
point in the underlying mop that would support a better way to  
support textual representation of first class field as in CLOS).

May be

Object subclass: Personn
        iv: 'name <CField...> firstname <k;lk;l>

or

Object subclass: Personn
        iv: 'name <CField...>' ;
         iv:  firstname <k;lk;l>

Because I think that syntax is still what we type in an old-fashion  
editor.
But this is another topic.

>> and I hate that the underlying representation of instance variable  
>> contain XML while this is totally unnecessary as I mentioned  
>> loooonnng time ago on the tweak mailing-list --- the smalltalk  
>> syntax is enough to declare property we do not need XML for that).
>
> The underlying representing does not contain XML.

Ok you change that then, or did not tell me the right answer to my  
original email long time ago

> The underlying representation is a CFieldDefinition which can -
> among other formats- be printed in XML.

>
> Cheers,
>   - Andreas
>

stéphane ducasse wrote:
>> No. They they contain *names* of variables, not variables themselves.
>
> So this means that during the compilation of the method you map the name
> to iv?

No. You can't map them during compilation since instance variables are
(as the name says) per-instance, not per class (besides the terminology
is "fields" precisely to distinguish them from raw slots, i.e., instance
variables). All that happens during compilation is a semantic
verification that this name is indeed the name of a field. Everything
else happens at runtime.

>>> and I hate that the underlying representation of instance variable
>>> contain XML while this is totally unnecessary as I mentioned
>>> loooonnng time ago on the tweak mailing-list --- the smalltalk syntax
>>> is enough to declare property we do not need XML for that).
>>
>> The underlying representing does not contain XML.
>
> Ok you change that then, or did not tell me the right answer to my
> original email long time ago

It has always been that way. Internally, the representation is an object
(a field definition). However, when you serialize the class (file out)
the definition is stored as XML. It could be anything - I opted for XML
because it was there, it worked, it was easy to use, and I have no
religious prejudices against it.

Cheers,
   - Andreas

On 21 août 06, at 01:55, Andreas Raab wrote:

> stéphane ducasse wrote:
>>> No. They they contain *names* of variables, not variables  
>>> themselves.
>> So this means that during the compilation of the method you map  
>> the name to iv?
>
> No. You can't map them during compilation since instance variables  
> are (as the name says) per-instance,

sure there are per instance but the offset in the underlying  
structure is the same.
so you are telling that you are not doing the same as in

class
        iv: x y w
foo
        ^ x

=> ok we will access offset one of the specific recever?

This is not about religious things this is about not tying a XML  
parser to a core of a system when
you can simply avoid it. Remember my emails.
        CField name: 'x' ; property: true.....
       
        support the expression you can express in XML




>
> Cheers,
>   - Andreas
>

stéphane ducasse schrieb:
You misunderstand completely. Suppose there is an event handler like this:

        showOptions
                <on: fire in: optionButton>
                optionDialog open

then the compiler simply verifies that there indeed is a field named
"optionButton". It does not care whether that field is an ivar (which
are the exception in Tweak) or a regular property. But it must be a
field so the runtime system can register a secondary event handler for
when that field changes (fields automatically generate change events
when modified). The field will initially be nil, but as soon as a
non-nil object is assigned, that secondary event handler registers the
actual event handler (#showOptions) with that object.

This is *exactly* what happens (see class CFieldDescription). You can
define fields that way if you want, but it would look horrible in a
browser's class definition.

Only for file-in and file-out the field descriptions are converted to a
String, which happens to contain XML. For display in the browser it is
converted to attributed Text.

Note that this is the same as for non-Tweak classes: instVar names are
stored as Symbol in an Array, but on file-in and file-out and for
browsing they are converted to a String.

- Bert -

On 21 août 06, at 10:42, Bert Freudenberg wrote:

Ok I understand better. Before I could not get what andreas was  
saying with per instance...

> This is *exactly* what happens (see class CFieldDescription). You  
> can define fields that way if you want, but it would look horrible  
> in a browser's class definition.
>
> Only for file-in and file-out the field descriptions are converted  
> to a String, which happens to contain XML.

So this means that you cannot load code without having an XML parser.

> For display in the browser it is converted to attributed Text.
>
> Note that this is the same as for non-Tweak classes: instVar names  
> are stored as Symbol in an Array, but on file-in and file-out and  
> for browsing they are converted to a String.

Yes but Symbol are more core than XMLparser :)
>
> - Bert -
>
>
>

Bert

do I understand correctly that you could then do the same

> showOptions
> <on: fire in: optionButton>
> optionDialog open
>

with <on: #fire in: #optionButton>
since this is the interpretation of the symbols that give them  
semantics.
ie mapping optionButton to a field.


Stef

stéphane ducasse schrieb:
If you insist on using "pragma syntax", yes. In Andreas' method property
implementation, this annotation indeed adds a property named #on:in:
with the value #(#fire #optionButton).

However, the missing # in the in: part indicates that this is *not* any
arbitrary symbol, whereas the event name is.

So for ultimate consistency it would need to be written as

        <on: #fire in: optionButton>

However, this would add a bit of visual clutter. And, it would look like
you could use a literal other than a Symbol for the event name. So the #
  is implied just like in a literal array.

- Bert -

On 21 août 06, at 14:47, Bert Freudenberg wrote:

I do not insist, I just want to understand :)

> In Andreas' method property implementation, this annotation indeed  
> adds a property named #on:in: with the value #(#fire #optionButton).
>
> However, the missing # in the in: part indicates that this is *not*  
> any arbitrary symbol, whereas the event name is.

Ok do you mean that I cannot put #zork but this is an event name.

> So for ultimate consistency it would need to be written as
>
> <on: #fire in: optionButton>
>
> However, this would add a bit of visual clutter. And, it would look  
> like you could use a literal other than a Symbol for the event  
> name. So the #  is implied just like in a literal array.

Ok so this means that basically there would not too much change to  
get something consistent with pragmas if we want.

Stef
>
> - Bert -
>
>
>
>

stéphane ducasse wrote:
>> However, the missing # in the in: part indicates that this is *not*
>> any arbitrary symbol, whereas the event name is.
>
> Ok do you mean that I cannot put #zork but this is an event name.

As a matter of fact I don't consider the event name to be "an arbitrary
symbol" - it needs to be the name of an event and if I would have had a
chance of ensuring that an event by that name exists, I would have added
the appropriate tests (both statically as well as dynamically). This is
the main reason why it's not #eventName.

I've been using pragmas side by side for a long time (I think longer
than Lukas or anybody else in Squeak ;-) I just called the <> constructs
annotations (and I still like this term better than pragma) but that's
about the only difference.

Cheers,
   - Andreas

PS. Got to catch a flight so I'll be offline for a day or so.