An alternative FFI/Parser proposal

stéphane ducasse ducasse at iam.unibe.ch
Mon Aug 21 06:29:47 UTC 2006


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?

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

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
>




More information about the Squeak-dev mailing list