[squeak-dev] The Inbox: EToys-hjh.333.mcz
cunningham.cb at gmail.com
Tue Jun 12 22:28:38 UTC 2018
On Mon, Jun 11, 2018 at 8:37 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Jun 11, 2018 at 11:29:49PM +0200, H. Hirzel wrote:
> > On 6/11/18, Chris Cunningham <cunningham.cb at gmail.com> wrote:
> > > On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <kksubbu.ml at gmail.com>
> > >
> > >> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
> > >>
> > >>> These two methods are sent by CircleMorph>>extent: in package
> > >>> so moving them from Etoys to Morphic seems the the right thing to do.
> > >>> Does anyone disagree?
> > >>
> > >> rotationCenter is an optional not an intrinsic geometric property like
> > >> bounds, extent etc. So should it be moved into the category "rotate
> > >> and flex"?
> > >>
> > >> rotationCenter also works with other properties like forwardDirection
> > >> They should also be considered for merging into Morphic. In fact, all
> > >> methods in Etoys-geometry could be moved to Morph as they don't use
> > >> anything specific to Etoys (player).
> > >
> > > Looking at the definitions in the image, there are 4 definitions of
> > > methods. The 3 definitions NOT in Etoys are in the method category
> > > 'geometry etoy'. So I'd suggest putting them there to at least have
> all of
> > > them in the same place.
> > So the proposal is to
> > a) to move all from category '*Etoys-geometry* to category *geometry
> > eToy* and then the two methods
> > rotationCenter and rotationCenter:
> > to category 'rotate scale and flex'
> I think that Chris Cunningham is supporting your original proposal to move
> rotationCenter and rotationCenter: from '*Etoys-geometry' in package Etoys
> to 'geometry eToy' in package Morphic.
> This seems right because it is consistent with other implementers of
> rotationCenter and rotationCenter: in Morphic.
> Subbu offered some additional suggestions, but let's get your original
> fix into trunk first :-)
that is what I intended.
Looking at what was committed, I think we should now move the other methods
of the same name on different objects/packages also into the more specific
method categories as well.
This could be the tip of the iceberg in re-classifying methods - I'm not
sure how far this wants to go before the release, but at least related same
methods should be categorized so the next person to encounter them see them
If no one beats me to it, I'll do that in before the next day passes
(especially since I seem to be more motivated by it at the moment).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev