about method annotations and trait fixes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

about method annotations and trait fixes

stéphane ducasse-2
Hi

I would like to know
        - when the annotations of lukas will be pushed in 3.9
        - adrian would it be possible to fix the trait problem
       
I would like to go beta soon.
And only integrate the stuff of smallland.

Marcus could you send me your list of pending items so that I can go  
over them.

Stef
Reply | Threaded
Open this post in threaded view
|

Re: about method annotations and trait fixes

Marcus Denker

On 05.02.2006, at 16:52, stéphane ducasse wrote:

> Hi
>
> I would like to know
> - when the annotations of lukas will be pushed in 3.9

I should have already done it. But I didn't. As soon as I find the
energy and the time, I hope next week.

> - adrian would it be possible to fix the trait problem
>
> I would like to go beta soon.
> And only integrate the stuff of smallland.
>
> Marcus could you send me your list of pending items so that I can  
> go over them.

I will have a look.

         Marcus

Reply | Threaded
Open this post in threaded view
|

Re: about method annotations and trait fixes

Lukas Renggli
> > I would like to know
> >       - when the annotations of lukas will be pushed in 3.9
>
> I should have already done it. But I didn't. As soon as I find the
> energy and the time, I hope next week.

I could provide a final and last change-set (this would be the 3rd
attempt then), if we can finally decide on the design. After a lot of
dicussion with Andreas and Marcus I would suggest the following
implementation:

- Every compiled method references an instance of MethodAnnotation, a
class providing a place for instance-variables that should have been
put into CompiledMethod if this was possible.

- MethodAnnotation has got an inst-var called pragmas, that holds a
collection of Pragmas that are added by the compiler at compile-time
from constructs like <foo>, <foo: 1>, <foo: 1 bar: 2>, etc and that
can be also reprinted to source when decompiling the CompiledMethod.

- MethodAnnotation has got an inst-var called properties, that is
initialized to nil but that might hold an identity-dictionary where
any kind of properties can be stored (or cached), such as source,
parse-tree, author initials, etc. The properties do not correspond to
something in the source-code and therefor do not require a change to
the parser/compiler/decompiler. Maybe this var could also be left-out
and we ask people to add i-vars consuming much less memory.

What do you think? Can everybody be happy with that?

Should I now do it the last time?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
Reply | Threaded
Open this post in threaded view
|

Re: about method annotations and trait fixes

Philippe Marschall
> What do you think? Can everybody be happy with that?

The definition class (fast #who) would be put where?

Philippe
Reply | Threaded
Open this post in threaded view
|

Re: about method annotations and trait fixes

Lukas Renggli
> The definition class (fast #who) would be put where?

The definition class is already within the last literal of
every-compiled method, this was already the case for all methods
calling super but is now true for all the methods within the image.

To answer your question: Other properties such as the selector of the
method, source-code, last modification date could be put into an
i-var/property of the MethodAnnotation object, since values like that
do not have a representation in the source-code.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
Reply | Threaded
Open this post in threaded view
|

Re: about method annotations and trait fixes

stéphane ducasse-2
In reply to this post by Lukas Renggli
if this solution is
        compatible with VW
        and let tweak working
Then this is good

When I read the email of andreas about the size (in german) and read  
your reply
it seems to me that this is ok.

May be we could send an email in the mailing-list (but this will slow  
down the process)
to get feedback?

Stef

On 5 févr. 06, at 19:42, Lukas Renggli wrote:

>>> I would like to know
>>>       - when the annotations of lukas will be pushed in 3.9
>>
>> I should have already done it. But I didn't. As soon as I find the
>> energy and the time, I hope next week.
>
> I could provide a final and last change-set (this would be the 3rd
> attempt then), if we can finally decide on the design. After a lot of
> dicussion with Andreas and Marcus I would suggest the following
> implementation:
>
> - Every compiled method references an instance of MethodAnnotation, a
> class providing a place for instance-variables that should have been
> put into CompiledMethod if this was possible.
>
> - MethodAnnotation has got an inst-var called pragmas, that holds a
> collection of Pragmas that are added by the compiler at compile-time
> from constructs like <foo>, <foo: 1>, <foo: 1 bar: 2>, etc and that
> can be also reprinted to source when decompiling the CompiledMethod.
>
> - MethodAnnotation has got an inst-var called properties, that is
> initialized to nil but that might hold an identity-dictionary where
> any kind of properties can be stored (or cached), such as source,
> parse-tree, author initials, etc. The properties do not correspond to
> something in the source-code and therefor do not require a change to
> the parser/compiler/decompiler. Maybe this var could also be left-out
> and we ask people to add i-vars consuming much less memory.
>
> What do you think? Can everybody be happy with that?
>
> Should I now do it the last time?
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>

Reply | Threaded
Open this post in threaded view
|

Re: about method annotations and trait fixes

Marcus Denker
In reply to this post by Lukas Renggli

On 05.02.2006, at 19:42, Lukas Renggli wrote:

>>> I would like to know
>>>       - when the annotations of lukas will be pushed in 3.9
>>
>> I should have already done it. But I didn't. As soon as I find the
>> energy and the time, I hope next week.
>
> I could provide a final and last change-set (this would be the 3rd
> attempt then), if we can finally decide on the design. After a lot of
> dicussion with Andreas and Marcus I would suggest the following
> implementation:
>
> - Every compiled method references an instance of MethodAnnotation, a
> class providing a place for instance-variables that should have been
> put into CompiledMethod if this was possible.
>

MethodExtension could be another name... don't really know if it is  
better,
but it would community quite clearly that this is state that should  
be in
the cm normally.

> - MethodAnnotation has got an inst-var called pragmas, that holds a
> collection of Pragmas that are added by the compiler at compile-time
> from constructs like <foo>, <foo: 1>, <foo: 1 bar: 2>, etc and that
> can be also reprinted to source when decompiling the CompiledMethod.
>
> - MethodAnnotation has got an inst-var called properties, that is
> initialized to nil but that might hold an identity-dictionary where
> any kind of properties can be stored (or cached), such as source,
> parse-tree, author initials, etc. The properties do not correspond to
> something in the source-code and therefor do not require a change to
> the parser/compiler/decompiler. Maybe this var could also be left-out
> and we ask people to add i-vars consuming much less memory.
>

I would like to have the properties... I guess mostly because adding
an instvars as an extension is not possible with MC... So for  
experiments,
it would be simpler.

state that all instvars have (like selector) should definitly be in  
an instVar.

> What do you think? Can everybody be happy with that?
>
Yes, sounds good.

> Should I now do it the last time?
>

Yes, would be nice!

        Marcus