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
|