An alternative FFI/Parser proposal

Bert Freudenberg bert at impara.de
Mon Aug 21 08:42:29 UTC 2006


stéphane ducasse schrieb:
> 
> 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?

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.

>>>> 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.
> 
> 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

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 -




More information about the Squeak-dev mailing list