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
|