[squeak-dev] The Inbox: EToys-hjh.333.mcz

David T. Lewis lewis at mail.msen.com
Tue Jun 12 22:36:19 UTC 2018


On Tue, Jun 12, 2018 at 03:28:38PM -0700, Chris Cunningham wrote:
> 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>
> > wrote:
> > > >
> > > >> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
> > > >>
> > > >>> These two methods are sent by CircleMorph>>extent: in package
> > Morphic-Basic,
> > > >>> 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
> > scale
> > > >> and flex"?
> > > >>
> > > >> rotationCenter also works with other properties like forwardDirection
> > etc.
> > > >> They should also be considered for merging into Morphic. In fact, all
> > the
> > > >> 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
> > these
> > > > 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 :-)
> >
> > Dave
> >
> Thanks Dave,
> 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
> consistently placed.
> 
> 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).
> 
> -cbc

Thanks Chris,

That sounds like a good idea, and it is all very low risk with respect
to the upcoming 5.2 release, so I see no reason that you should not go
ahead and re-classify where appropriate.

Dave



More information about the Squeak-dev mailing list