Hi all,
as you know I'm working on stateful traits using my new classbuilder
etc... Now I noticed that methods are highlighted always inside of the
context of the class that's active in the class browser. How can I
change this? There is already a useful method around to figure out which
objec
Ok, found it out by myself. I just hooked into OB directly:
OBMethodDefinition>
shouldBeStyledBy: aPluggableShoutMorph
aPluggableShoutMorph classOrMetaClass: (theClass
traitOrClassOfSelector: self selector).
^ true
cheers,
Toon
On 04/02/2011 09:10 PM, Toon Verwaest wrote:
Hi all,
as
On Apr 2, 2011, at 9:10 PM, Toon Verwaest wrote:
> Hi all,
>
> as you know I'm working on stateful traits using my new classbuilder
no
Are you?
> etc... Now I noticed that methods are highlighted always inside of the
> context of the class that's active in the class browser. How can I chang
Oh yes.. I am :)
http://pinocchio.unibe.ch/~tverwaes/slots.tar.gz gives you an image with
an example of a stateful trait open. The state is always private to the
class / trait at the moment and it already seems to work pretty well. I
modified the NewInspector slightly to show you the proper da
> Oh yes.. I am :)
cool
How are you dealing with the fact that the application of trait with state may
change the layout of the class user and that you should recompile
all the class method to deal with that. And if you have two traits having state
you should do the same but for the traits the
How are you dealing with the fact that the application of trait with state may
change the layout of the class user and that you should recompile
all the class method to deal with that. And if you have two traits having state
you should do the same but for the traits themselves.
So this means t
Then the classbuilder will build classes by always following the
public path. Sidescopes aren't public. When you compile methods on the
trait, its scopes are public; but when they are installed, they aren't
public since they are sidescopes.
I obviously meant, the compiler will compile methods
> So now I could apply syntax coloring in the context of the trait rather than
> the class.
Do you mean coloring message sends in a trait's method? For self call that is
not specified in the requirement?
> Since in my implementation state is all private to the trait / class, they
> should be a
Do you mean coloring message sends in a trait's method? For self call that is
not specified in the requirement?
I meant that if you look at a method coming from a trait inside of the
class browser; while your browser is pointing at a class. Instance
variables were colored red since they weren
I tried the image. I hadn't seen such a look for years :-)
StatefulTrait named: #TStatefulTest
layout: PointerLayout
slots: {
#tfirst => Slot.
#tsecond => Slot.
}
uses: {}
category: #'Slot-Traits-Test'
I checked what layout:
I just finished building a new image based on the helvetia image.
http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz
The previous image is what I've been developing in, and yes, it's pretty
annoying... I hope that the new image will perform better. But since I
already noticed that the new insp
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf)
We have T.y an
>> Can you merge state? What happens with C.x uses T.x ? Methods of T will use
>> T.x and methods of C will use C.x?
>>
> At the moment you can't, but in our slot library we have alias slots. So that
> we could use to do the same tricks as with methods: required slots, provided
> slots, "defros
On 04/03/2011 02:29 PM, Alexandre Bergel wrote:
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
http://bergel.eu/download/
On 04/03/2011 02:31 PM, Alexandre Bergel wrote:
Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x
and methods of C will use C.x?
At the moment you can't, but in our slot library we have alias slots. So that we could
use to do the same tricks as with methods: requ
> Yes I see, I did forget to implement all the tools to make it work. You
> know... I started the stateful traits implementation on Friday... I'm glad
> that I'm as far as I am ;) However, in the new image I can close it.
> Exceptions are just very slow for some reason.
This is cool that you're
On 04/03/2011 02:31 PM, Alexandre Bergel wrote:
Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x
and methods of C will use C.x?
At the moment you can't, but in our slot library we have alias slots. So that we could
use to do the same tricks as with methods: requ
> Indeed. And this is not different from changing a layout of a class having as
> impact that you have to update the methods.
> The default traits implementation already recompiles all methods anyway
> whenever it installs the trait. What I do is, I just let the trait compile
> itself on the sub
On Apr 3, 2011, at 1:29 PM, Alexandre Bergel wrote:
> I guess that what Stef meant is the following:
> One of the problems when sharing code among mixin and stateful-trait
> application is that the physical layout of instances varies between mixin
> applications. (Section 6.5 of
Yes, and the
On 04/03/2011 02:37 PM, Alexandre Bergel wrote:
Indeed. And this is not different from changing a layout of a class having as
impact that you have to update the methods.
The default traits implementation already recompiles all methods anyway
whenever it installs the trait. What I do is, I just
On 04/03/2011 02:29 PM, Alexandre Bergel wrote:
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
http://bergel.eu/download/
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
- the initialization is not modular so you end up write a lot o
On 04/03/2011 04:58 PM, Stéphane Ducasse wrote:
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
I'm not sure if it cha
>> Thanks I should digest it.
>> Now what I did not like in our stateful model was that
>> - in introduced too many operators
>> - I'm not sure I like trait state to be private because it changes a
>> lot the smalltalk model
At least, Toon will avoid all the problems we had with the ren
On 04/03/2011 06:46 PM, Alexandre Bergel wrote:
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
At least, Toon will a
>>
> Another very cool thing that we can do now (which would require 3 lines of
> change in my system though), is that the slot can also be responsible for
> instance migration. There are four cases:
> 1- the instance variable didn't exist and now it does
> 2- the instance variable existed but d
I want to read the paper :)
Stef
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
>> At least, Toon will
On 04/04/2011 05:55 PM, Stéphane Ducasse wrote:
Another very cool thing that we can do now (which would require 3 lines of
change in my system though), is that the slot can also be responsible for
instance migration. There are four cases:
1- the instance variable didn't exist and now it does
2-
Do you have an exact reference on this?
On 04/04/2011 05:55 PM, Stéphane Ducasse wrote:
Another very cool thing that we can do now (which would require 3 lines of
change in my system though), is that the slot can also be responsible for
instance migration. There are four cases:
1- the instance
he he. I am not sure Fred wrote in English.
http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard
Cheers,
Alexandre
On 4 Apr 2011, at 14:15, Toon Verwaest wrote:
> Do you have an exact reference on this?
>
> On 04/04/2011 05:55 PM, Stéphane Ducasse wrote:
>>> Another very cool thing that we can
I do read French too, no problem.
I'm having a look at
http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps
That seems related.
On 04/04/2011 09:20 PM, Alexandre Bergel wrote:
he he. I am not sure Fred wrote in English.
http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard
Cheers,
Alexand
Did you check the work of fred rivard because he was managing the dynamic
change of class and managing slot reinitialization?
As far as I can tell from his paper he's mostly interested in the
"accept instance" to modify instances from one class to another. This
forces you to write the full ma
In fact he got a better changeClassToThatOf: implementation and got kind of
initform for slots.
Stef
> I do read French too, no problem.
>
> I'm having a look at
>
> http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps
>
> That seems related.
>
> On 04/04/2011 09:20 PM, Alexandre Berge
I remember Fred has lazy initialization of variable. All variables are lazy
initialized. This means that variables set to nil when you change the class are
lazy initialized.
It has been a long time I looked at it.
Alexandre
On 4 Apr 2011, at 16:32, Stéphane Ducasse wrote:
> In fact he got a b
Yes, I read those two things too... but it doesn't seem like a giant
leap of an improvement :)
On 04/05/2011 02:34 PM, Alexandre Bergel wrote:
I remember Fred has lazy initialization of variable. All variables are lazy
initialized. This means that variables set to nil when you change the class
35 matches
Mail list logo
