Proposal to refactor MethodFinder with pragmas

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

Proposal to refactor MethodFinder with pragmas

Damien Cassou
Currently MethodFinder uses a list of acceptable selectors to execute.
This list of selectors is not maintained which results in a lot of
selectors to exist only in this list as they have been removed in the
system. I propose to use pragmas on classes to generate this list
automatically.

Here is an example

Magnitude class>>finderApprovedMethods
       <finderApproveInstanceMethod: #max:>
       <finderApproveInstanceMethod: #min:>
       <finderApproveInstanceMethod: #min:max:>
       <finderApproveInstanceMethod: #< >
       <finderApproveInstanceMethod: #<= >
       <finderApproveInstanceMethod: #< >
       <finderApproveInstanceMethod: #<= >
       <finderApproveInstanceMethod: #between:and: >

What do you think?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Pavel Krivanek-3
What about only to use a pragma directly in the methods that will
inform that the method has no side effect and doesn't modify the state
of the object? This information may be used not only for the
MethodFinder.

-- Pavel

On Fri, Jun 24, 2011 at 11:25 AM, Damien Cassou <[hidden email]> wrote:

> Currently MethodFinder uses a list of acceptable selectors to execute.
> This list of selectors is not maintained which results in a lot of
> selectors to exist only in this list as they have been removed in the
> system. I propose to use pragmas on classes to generate this list
> automatically.
>
> Here is an example
>
> Magnitude class>>finderApprovedMethods
>       <finderApproveInstanceMethod: #max:>
>       <finderApproveInstanceMethod: #min:>
>       <finderApproveInstanceMethod: #min:max:>
>       <finderApproveInstanceMethod: #< >
>       <finderApproveInstanceMethod: #<= >
>       <finderApproveInstanceMethod: #< >
>       <finderApproveInstanceMethod: #<= >
>       <finderApproveInstanceMethod: #between:and: >
>
> What do you think?
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Damien Cassou
On Fri, Jun 24, 2011 at 11:34 AM, Pavel Krivanek
<[hidden email]> wrote:
> What about only to use a pragma directly in the methods that will
> inform that the method has no side effect and doesn't modify the state
> of the object? This information may be used not only for the
> MethodFinder.

I would prefer your solution. But since there is currently no other
user for this pragma, the result would be the same cluttering that
people complained with previously. What do others think?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

abergel
In reply to this post by Damien Cassou
Why not something like

Magnitude class>>finderApprovedMethods
        ^ {#max: . #min: . #min:max: . #< . ... }

It is shorter and less magic is involved here. It will also be probably faster to do a query.

Cheers,
Alexandre

On 24 Jun 2011, at 05:25, Damien Cassou wrote:

> Currently MethodFinder uses a list of acceptable selectors to execute.
> This list of selectors is not maintained which results in a lot of
> selectors to exist only in this list as they have been removed in the
> system. I propose to use pragmas on classes to generate this list
> automatically.
>
> Here is an example
>
> Magnitude class>>finderApprovedMethods
>       <finderApproveInstanceMethod: #max:>
>       <finderApproveInstanceMethod: #min:>
>       <finderApproveInstanceMethod: #min:max:>
>       <finderApproveInstanceMethod: #< >
>       <finderApproveInstanceMethod: #<= >
>       <finderApproveInstanceMethod: #< >
>       <finderApproveInstanceMethod: #<= >
>       <finderApproveInstanceMethod: #between:and: >
>
> What do you think?
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Pavel Krivanek-3
It is an extra list that has to be maintained. And what package will
own this method?

-- Pavel

On Fri, Jun 24, 2011 at 2:26 PM, Alexandre Bergel
<[hidden email]> wrote:

> Why not something like
>
> Magnitude class>>finderApprovedMethods
>        ^ {#max: . #min: . #min:max: . #< . ... }
>
> It is shorter and less magic is involved here. It will also be probably faster to do a query.
>
> Cheers,
> Alexandre
>
> On 24 Jun 2011, at 05:25, Damien Cassou wrote:
>
>> Currently MethodFinder uses a list of acceptable selectors to execute.
>> This list of selectors is not maintained which results in a lot of
>> selectors to exist only in this list as they have been removed in the
>> system. I propose to use pragmas on classes to generate this list
>> automatically.
>>
>> Here is an example
>>
>> Magnitude class>>finderApprovedMethods
>>       <finderApproveInstanceMethod: #max:>
>>       <finderApproveInstanceMethod: #min:>
>>       <finderApproveInstanceMethod: #min:max:>
>>       <finderApproveInstanceMethod: #< >
>>       <finderApproveInstanceMethod: #<= >
>>       <finderApproveInstanceMethod: #< >
>>       <finderApproveInstanceMethod: #<= >
>>       <finderApproveInstanceMethod: #between:and: >
>>
>> What do you think?
>>
>> --
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>>
>> "Lambdas are relegated to relative obscurity until Java makes them
>> popular by not having them." James Iry
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Stéphane Ducasse
In reply to this post by abergel
Yes
we were wondering with igor why using pragmas and that a simple list would be enough.

Stef

On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote:

> Why not something like
>
> Magnitude class>>finderApprovedMethods
> ^ {#max: . #min: . #min:max: . #< . ... }
>
> It is shorter and less magic is involved here. It will also be probably faster to do a query.
>
> Cheers,
> Alexandre
>
> On 24 Jun 2011, at 05:25, Damien Cassou wrote:
>
>> Currently MethodFinder uses a list of acceptable selectors to execute.
>> This list of selectors is not maintained which results in a lot of
>> selectors to exist only in this list as they have been removed in the
>> system. I propose to use pragmas on classes to generate this list
>> automatically.
>>
>> Here is an example
>>
>> Magnitude class>>finderApprovedMethods
>>      <finderApproveInstanceMethod: #max:>
>>      <finderApproveInstanceMethod: #min:>
>>      <finderApproveInstanceMethod: #min:max:>
>>      <finderApproveInstanceMethod: #< >
>>      <finderApproveInstanceMethod: #<= >
>>      <finderApproveInstanceMethod: #< >
>>      <finderApproveInstanceMethod: #<= >
>>      <finderApproveInstanceMethod: #between:and: >
>>
>> What do you think?
>>
>> --
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>>
>> "Lambdas are relegated to relative obscurity until Java makes them
>> popular by not having them." James Iry
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

carlo.t
... because using method is old school and pragma's are new school ;)  (Java annotations anyone)

Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention.
At the end of the day both solutions will work but if we are going to aggregate all the MethodFinder acceptable selectors into a class method then we may as well drop the pragma...

On 24 Jun 2011, at 3:41 PM, Stéphane Ducasse wrote:

Yes
we were wondering with igor why using pragmas and that a simple list would be enough.

Stef

On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote:

> Why not something like
>
> Magnitude class>>finderApprovedMethods
> ^ {#max: . #min: . #min:max: . #< . ... }
>
> It is shorter and less magic is involved here. It will also be probably faster to do a query.
>
> Cheers,
> Alexandre
>
> On 24 Jun 2011, at 05:25, Damien Cassou wrote:
>
>> Currently MethodFinder uses a list of acceptable selectors to execute.
>> This list of selectors is not maintained which results in a lot of
>> selectors to exist only in this list as they have been removed in the
>> system. I propose to use pragmas on classes to generate this list
>> automatically.
>>
>> Here is an example
>>
>> Magnitude class>>finderApprovedMethods
>>    <finderApproveInstanceMethod: #max:>
>>    <finderApproveInstanceMethod: #min:>
>>    <finderApproveInstanceMethod: #min:max:>
>>    <finderApproveInstanceMethod: #< >
>>    <finderApproveInstanceMethod: #<= >
>>    <finderApproveInstanceMethod: #< >
>>    <finderApproveInstanceMethod: #<= >
>>    <finderApproveInstanceMethod: #between:and: >
>>
>> What do you think?
>>
>> --
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>>
>> "Lambdas are relegated to relative obscurity until Java makes them
>> popular by not having them." James Iry
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

abergel
> ... because using method is old school and pragma's are new school ;)  (Java annotations anyone)
>
> Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention.
> At the end of the day both solutions will work but if we are going to aggregate all the MethodFinder acceptable selectors into a class method then we may as well drop the pragma...

Have a look at the help browser. It is slow because of global pragma queries.
Having a method Behavior>>finderApprovedMethods looks perfectly okay to me.

Cheers,
Alexandre

>
> On 24 Jun 2011, at 3:41 PM, Stéphane Ducasse wrote:
>
> Yes
> we were wondering with igor why using pragmas and that a simple list would be enough.
>
> Stef
>
> On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote:
>
>> Why not something like
>>
>> Magnitude class>>finderApprovedMethods
>> ^ {#max: . #min: . #min:max: . #< . ... }
>>
>> It is shorter and less magic is involved here. It will also be probably faster to do a query.
>>
>> Cheers,
>> Alexandre
>>
>> On 24 Jun 2011, at 05:25, Damien Cassou wrote:
>>
>>> Currently MethodFinder uses a list of acceptable selectors to execute.
>>> This list of selectors is not maintained which results in a lot of
>>> selectors to exist only in this list as they have been removed in the
>>> system. I propose to use pragmas on classes to generate this list
>>> automatically.
>>>
>>> Here is an example
>>>
>>> Magnitude class>>finderApprovedMethods
>>>   <finderApproveInstanceMethod: #max:>
>>>   <finderApproveInstanceMethod: #min:>
>>>   <finderApproveInstanceMethod: #min:max:>
>>>   <finderApproveInstanceMethod: #< >
>>>   <finderApproveInstanceMethod: #<= >
>>>   <finderApproveInstanceMethod: #< >
>>>   <finderApproveInstanceMethod: #<= >
>>>   <finderApproveInstanceMethod: #between:and: >
>>>
>>> What do you think?
>>>
>>> --
>>> Damien Cassou
>>> http://damiencassou.seasidehosting.st
>>>
>>> "Lambdas are relegated to relative obscurity until Java makes them
>>> popular by not having them." James Iry
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Lukas Renggli
In reply to this post by carlo.t
> Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention.

FYI, the refactoring engine supports pragmas and can for example rename them.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Gary Chambers-4
Seems to me, unless individual methods are annotated (or assumed safe/unsafe
if not) that we would still be having to maintain a list that probably
wouldn't be maintained...

Just a thought.

Regards, Gary


----- Original Message -----
From: "Lukas Renggli" <[hidden email]>
To: <[hidden email]>
Sent: Friday, June 24, 2011 3:03 PM
Subject: Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas


>> Arguably using pragma's is cleaner approach to specify orthogonal
>> concerns but without full IDE support (refactorings etc to minimize
>> unmaintained pragma's) I would argue for just using a method and package
>> based on convention.
>
> FYI, the refactoring engine supports pragmas and can for example rename
> them.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

Damien Cassou
On Fri, Jun 24, 2011 at 5:52 PM, Gary Chambers
<[hidden email]> wrote:
> Seems to me, unless individual methods are annotated (or assumed safe/unsafe
> if not) that we would still be having to maintain a list that probably
> wouldn't be maintained...

I agree with all of you. To sum up:

- we could add a pragma per method to indicate that the method can be
called by the finder or better, that it is side-effect=free (not sure
though that side-effect-free = usable-by-methodfinder)

other solutions require maintenance, but simpler ones because if you
remove the class you also remove the list of methods. These solutions
are:

- one method per class containing a list of pragmas. Pragmas should be
found easily by using a PragmaCollector (I believe that the use of
PragmaCollector should make lookup very fast)

- one method per class returning a list of selectors. I guess we could
use the Announcer to be notified when this particular method is loaded
or updated.

What do you think?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to refactor MethodFinder with pragmas

cbc
On Fri, Jun 24, 2011 at 9:47 AM, Damien Cassou <[hidden email]> wrote:
> - one method per class returning a list of selectors. I guess we could
> use the Announcer to be notified when this particular method is loaded
> or updated.

Of equal/more importance, when a method referenced by this method is
removed, it needs to update this referencing method.  Even more
interesting, when a method is added to the class that is side-effect
free and MethodFinder friendly, it should be added to the list
(although that would be fun to figure out programmatically).  Also, if
a method is updated to have side-effects, it should be removed from
this list as well, although this doesn't happen very often.

-Chris