accessors entry in submenu of refactor class menu (OB package Browser)

Is it by design decision:

That we don't have a way to create accessor (specifically the getters) that do lazy evaluation?

The way the tool works now is that if one clicks refactor->accessors you get a new window with all accessors "created" and you have to delete the ones you don't want?

And last but not least, if I attempt to edit a method in the new window "Changes: refactor class, accessors" I get an MNU: OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass.

--
Cesar Rabak
 




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> That we don't have a way to create accessor (specifically the getters) that do lazy evaluation?

Lazy initialization? What do you want to do?

> The way the tool works now is that if one clicks refactor->accessors you get a new window with all accessors "created" and you have to delete the ones you don't want?

You can disable the preference #promptOnRefactoring to not display the
changes and perform the refactoring immediately.

> And last but not least, if I attempt to edit a method in the new window "Changes: refactor class, accessors" I get an MNU: OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass.

I cannot reproduce the problem in the standard OmniBrowser. I commonly
edit the changes before applying the refactorings.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Em 12/11/2009 19:08, Lukas Renggli <[hidden email]> escreveu:

> > That we don't  have a  way to  create accessor  (specifically the
> > getters) that do lazy evaluation?
>  Lazy initialization? What do you want to do?

SomeClass>>aVariable

    aVariable isNil ifTrue: [aVariable := "sensible thing to do"].
    ^aVariable

Most of the cases you will have the creation of an object or have the
variable set to zero in the block.

> > The   way   the  tool   works   now   is   that  if   one   clicks
> > refactor->accessors  you  get  a  new window  with  all  accessors
> > "created" and you have to delete the ones you don't want?
>  You can disable the  preference #promptOnRefactoring to not display
>  the changes and perform the refactoring immediately.

This is the opposite I'm searching!  

>  > And last but not least, if  I attempt to edit a method in the new
>  > window  "Changes:   refactor  class,   accessors"  I  get   an  MNU:
>  > OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass.
>  I  cannot reproduce  the  problem in  the  standard OmniBrowser.  I
>  commonly edit the changes before applying the refactorings.

This is happening in an image: Pharo1.0rc1 Latest update: #10495

--
Cesar Rabak



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> > That we don't  have a  way to  create accessor  (specifically the
>> > getters) that do lazy evaluation?
>>  Lazy initialization? What do you want to do?
>
> SomeClass>>aVariable
>
>    aVariable isNil ifTrue: [aVariable := "sensible thing to do"].
>    ^aVariable

How would the refactoring engine figure out what you want to do?

Normally you just change the code directly in the changes browser.

>>  > And last but not least, if  I attempt to edit a method in the new
>>  > window  "Changes:   refactor  class,   accessors"  I  get   an  MNU:
>>  > OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass.
>>  I  cannot reproduce  the  problem in  the  standard OmniBrowser.  I
>>  commonly edit the changes before applying the refactorings.
>
> This is happening in an image: Pharo1.0rc1 Latest update: #10495

Looks like a bug in OCompletion.

I am still using ECompletion, so I've not seen that bug before.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> This is happening in an image: Pharo1.0rc1 Latest update: #10495
>
> Looks like a bug in OCompletion.
>
> I am still using ECompletion, so I've not seen that bug before.

Ahh, now I understand the problem. It also happens with ECompletion,
you just have to press tab there to make it visible. I've published a
workaround with:

Name: OB-Refactory-lr.170
Author: lr
Time: 12 November 2009, 10:36:05 pm
UUID: f337e63c-fb96-4339-b9e8-a000e90fc075
Ancestors: OB-Refactory-lr.169

- fixed a bug with ECompletion/OCompletion when somebody wanted to
complete something in the changes browser

Cheers,
Lukas


--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Em 12/11/2009 19:29, Lukas Renggli <[hidden email]> escreveu:

> >> > That we don't  have a way to create  accessor (specifically the
> >> > getters) that do lazy evaluation?
> >> Lazy initialization? What do you want to do?
> > SomeClass>>aVariable
> > aVariable  isNil ifTrue:  [aVariable :=  "sensible thing  to do"].
> >    ^aVariable
>  How would the refactoring engine figure out what you want to do?

We just give it some hints.  To have an example of this functionality
pls get a look at the page nine of http://cormas.cirad.fr/forum/cormas/old2004_2006/att-0518/01-IntroCormas_Elections.pdf

>  Normally you just change the code directly in the changes browser.
>

I see, was my plan B, but I'm experiencing the bug I describe...

> >>  > And last but  not least, if I attempt to edit  a method in the
> >>  > new window "Changes: refactor  class, accessors" I get an MNU:
> >>  > OR2AddMethodChangeNode(Object)>>doesNotUnderstand:
> >>  > #selectedClass.
> >>  I cannot  reproduce the problem in the  standard OmniBrowser.  I
> >>  commonly edit the changes before applying the refactorings.
> > This is happening in an image: Pharo1.0rc1 Latest update: #10495
>  Looks like a bug in OCompletion.
>  I am still using ECompletion, so I've not seen that bug before.

OK.  This begs the question: which of the completions engines is
supposed to be the 'official' one?

Regards,

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/13  <[hidden email]>:
Are you working with Cormas ?

--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Smalltalkers do: [:it | All with: Class, (And love: it)]
http://doesnotunderstand.org/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project