17 Jan
2012
17 Jan
'12
6:01 p.m.
Highlights:
* Magritte descriptions now work on the instance side
* /magritte/editor works with instance side descriptions
* Refactoring support to move descriptions to instance side
Details:
* All code is in the repository:
http://source.lukas-renggli.ch/magritte2unstable
* Taking feedback from previous mail pragmas are now named: <*
magritteDescription*>, <*magritteDescription:* #extensionMethod>,
<magritteContainer> respectively for descriptions, descriptions extensions
and description containers (description containers extensions do exist,
they use the same pragma <magritteContainer> but take the container as a
parameter).
* All tests are green, and the /magritte/editor works.
* The refactoring supports works at the method, class and
class-category/package level. It adds the appropriate pragma for
descriptions, description extensions and container descriptions. The
methods keep the same category (this is to avoid package extensions methods
inadvertantly being reclassified). I attempted renaming #descriptionAddress
to #addressDescription but it complicated description extensions so I
decided to keep things simple. The refactoring support can be loaded from
Magritte-Tools. Before you try the refactoring, read the caveats below.
Caveats:
* I've ported but haven't tested the Morphic bindings. Be great if someone
who knows the Morphic bindings can test.
* The refactoring will not add 'class' for class-side selectors. For
example the following description:
descriptionGroup
^ MAStringDescription new
accessor: #group;
default: self defaultGroup;
label: 'Group';
priority: 105;
yourself
will be refactored to:
descriptionGroup
<magritteDescription>
^ MAStringDescription new
accessor: #group;
default: self defaultGroup;
label: 'Group';
priority: 105;
yourself
However you'll have to manually add a 'class' to 'self defaultGroup'
to
make it 'self class defaultGroup' .... unless someone knows how to fix
this?...
* all instance side #description & #description: selectors within
MADescription and MAMemento hierarchy have been renamed to
#magritteDescription
& #magritteDescription: respectively. I've tried to catch all senders of
#description and change them to #magritteDescription. However instance
creation methods have kept their original naming for example MAMemento
class>>model:description:
Next Steps:
Attempt to refactor Pier and fix bugs based on feedback.... over to you....
Nick
17 Jan
17 Jan
6:09 p.m.
If you want to try it out you'll have to ensure MAPragmaBuilder is used by
resetting the builder:
MADescriptionBuilder default: nil.
[ once you've loaded the code from:
http://source.lukas-renggli.ch/magritte2unstable ]
6:13 p.m.
See attached screen grabs showing how to access the refactoring support at
a method, class and package level.
6:18 p.m.
On 17 January 2012 18:01, Nick Ager <nick.ager(a)gmail.com> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
Highlights:
* Magritte descriptions now work on the instance side
* /magritte/editor works with instance side descriptions
* Refactoring support to move descriptions to instance side
Details:
* All code is in the
repository: http://source.lukas-renggli.ch/magritte2unstable
* Taking feedback from previous mail pragmas are now
named: <magritteDescription>, <magritteDescription: #extensionMethod>,
<magritteContainer> respectively for descriptions, descriptions extensions
and description containers (description containers extensions do exist, they
use the same pragma <magritteContainer> but take the container as a
parameter).
* All tests are green, and the /magritte/editor works.
* The refactoring supports works at the method, class and
class-category/package level. It adds the appropriate pragma for
descriptions, description extensions and container descriptions. The methods
keep the same category (this is to avoid package extensions methods
inadvertantly being reclassified). I attempted renaming #descriptionAddress
to #addressDescription but it complicated description extensions so I
decided to keep things simple. The refactoring support can be loaded from
Magritte-Tools. Before you try the refactoring, read the caveats below.
Awesome news!
Caveats:
* I've ported but haven't tested the Morphic bindings. Be great if someone
who knows the Morphic bindings can test.
* The refactoring will not add 'class' for class-side selectors. For
example the following description:
I guess this is good enough for most users. Also in OB-Refactory there
is an action where you can move a method with one click on the
instance/class side.
Lukas
descriptionGroup
^ MAStringDescription new
accessor: #group;
default: self defaultGroup;
label: 'Group';
priority: 105;
yourself
will be refactored to:
descriptionGroup
<magritteDescription>
^ MAStringDescription new
accessor: #group;
default: self defaultGroup;
label: 'Group';
priority: 105;
yourself
However you'll have to manually add a 'class' to 'self defaultGroup'
to make
it 'self class defaultGroup' .... unless someone knows how to fix this?...
* all instance side #description & #description: selectors within
MADescription and MAMemento hierarchy have been renamed to
#magritteDescription & #magritteDescription: respectively. I've tried to
catch all senders of #description and change them to #magritteDescription.
However instance creation methods have kept their original naming for
example MAMemento class>>model:description:
Next Steps:
Attempt to refactor Pier and fix bugs based on feedback.... over to you....
Nick
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
6:28 p.m.
* The refactoring will not add 'class'
for class-side selectors. For
I guess this is good enough for most users. Also in OB-Refactory there
is an action where you can move a method with one click on the
instance/class side.
yes I looked at the move instance/class side refactoring but it seems to
6:33 p.m.
On 17 January 2012 18:28, Nick Ager <nick.ager(a)gmail.com> wrote:
yes I looked at the move instance/class side refactoring but it seems to
suffer from the same problem - unless I've missed something
Yeah, it doesn't pull other methods along. That is quite hard to do in
a dynamic language and might get out of hands pretty quickly. I was
just trying to say, that it is easy to fix manually afterwards.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
* The refactoring will not add 'class' for
class-side selectors. For
I guess this is good enough for most users. Also in OB-Refactory there
is an action where you can move a method with one click on the
instance/class side.
6:41 p.m.
Yeah, it doesn't pull other methods along. That is quite hard to do in
a dynamic language and might get out of hands pretty quickly. I was
just trying to say, that it is easy to fix manually afterwards.
OK, my approach so far has been to keep the methods which the descriptions
access on the class side as most of them seem to be defaults which feel at
home on the class-side.
4726
days inactive
4726
days old
7 comments
2 participants
participants (2)
-
Lukas Renggli -
Nick Ager