The Inbox: EToys-hjh.333.mcz

> A new version of EToys was added to project The Inbox:
> http://source.squeak.org/inbox/EToys-hjh.333.mcz
>
> ==================== Summary ====================
>
> Name: EToys-hjh.333
> Author: hjh
> Time: 11 June 2018, 7:47:07.644259 am
> UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
> Ancestors: EToys-nice.332
>
> Move methods
> Morph rotationCenter and rotationCenter:
> from 'Etoys-geometry' to 'geometry'
>
> =============== Diff against EToys-nice.332 ===============
>
> Item was removed:
> - ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry') -----
> - rotationCenter
> - "Return the rotation center of the receiver. The rotation center defines
> the relative offset inside the receiver's bounds for locating the reference
> position."
> - ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
> - !
>
> Item was removed:
> - ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry') -----
> - rotationCenter: aPointOrNil
> - "Set the new rotation center of the receiver. The rotation center defines
> the relative offset inside the receiver's bounds for locating the reference
> position."
> - aPointOrNil isNil
> - ifTrue:[self removeProperty: #rotationCenter]
> - ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
> - !
>
>
>

> The two methods
>
>
> Morph rotationCenter and
> Morph rotationCenter:
>
> need to be moved from the  'Etoys-geometry' category to the
> 'geometry' category in order to avoid an immediate crash after
> unloading Etoys.
>
> See http://wiki.squeak.org/squeak/1156
>
> I am not sure how this re-categorisation has to be done.
>
> On Mon, 11 Jun 2018 05:47:31 0000, [hidden email]
> <[hidden email]> wrote:
>> A new version of EToys was added to project The Inbox:
>> http://source.squeak.org/inbox/EToys-hjh.333.mcz
>>
>> ==================== Summary ====================
>>
>> Name: EToys-hjh.333
>> Author: hjh
>> Time: 11 June 2018, 7:47:07.644259 am
>> UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
>> Ancestors: EToys-nice.332
>>
>> Move methods
>> Morph rotationCenter and rotationCenter:
>> from 'Etoys-geometry' to 'geometry'
>>
>> =============== Diff against EToys-nice.332 ===============
>>
>> Item was removed:
>> - ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry')
>> -----
>> - rotationCenter
>> - "Return the rotation center of the receiver. The rotation center
>> defines
>> the relative offset inside the receiver's bounds for locating the
>> reference
>> position."
>> - ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
>> - !
>>
>> Item was removed:
>> - ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry')
>> -----
>> - rotationCenter: aPointOrNil
>> - "Set the new rotation center of the receiver. The rotation center
>> defines
>> the relative offset inside the receiver's bounds for locating the
>> reference
>> position."
>> - aPointOrNil isNil
>> - ifTrue:[self removeProperty: #rotationCenter]
>> - ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
>> - !
>>
>>
>>
>

> Package Morphic as the receiver of this change needs an update as well.
>
> On 6/11/18, H. Hirzel <[hidden email]> wrote:
> > The two methods
> >
> >
> > Morph rotationCenter and
> > Morph rotationCenter:
> >
> > need to be moved from the  'Etoys-geometry' category to the
> > 'geometry' category in order to avoid an immediate crash after
> > unloading Etoys.
> >
> > See http://wiki.squeak.org/squeak/1156
> >
> > I am not sure how this re-categorisation has to be done.
> >
> > On Mon, 11 Jun 2018 05:47:31 0000, [hidden email]
> > <[hidden email]> wrote:
> >> A new version of EToys was added to project The Inbox:
> >> http://source.squeak.org/inbox/EToys-hjh.333.mcz
> >>
> >> ==================== Summary ====================
> >>
> >> Name: EToys-hjh.333
> >> Author: hjh
> >> Time: 11 June 2018, 7:47:07.644259 am
> >> UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
> >> Ancestors: EToys-nice.332
> >>
> >> Move methods
> >> Morph rotationCenter and rotationCenter:
> >> from 'Etoys-geometry' to 'geometry'
> >>
> >> =============== Diff against EToys-nice.332 ===============
> >>
> >> Item was removed:
> >> - ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry')
> >> -----
> >> - rotationCenter
> >> - "Return the rotation center of the receiver. The rotation center
> >> defines
> >> the relative offset inside the receiver's bounds for locating the
> >> reference
> >> position."
> >> - ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
> >> - !
> >>
> >> Item was removed:
> >> - ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry')
> >> -----
> >> - rotationCenter: aPointOrNil
> >> - "Set the new rotation center of the receiver. The rotation center
> >> defines
> >> the relative offset inside the receiver's bounds for locating the
> >> reference
> >> position."
> >> - aPointOrNil isNil
> >> - ifTrue:[self removeProperty: #rotationCenter]
> >> - ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
> >> - !
> >>
> >>
> >>
> >
>

> 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'
>
> -- HJH
>
>
> On 6/11/18, Chris Cunningham <[hidden email]> wrote:
>> On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> 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).
>>>
>>> Regards .. Subbu
>>>
>>> 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.
>>
>> -cbc
>>
>

>
> On 6/11/18, Chris Cunningham <[hidden email]> wrote:
>
> > On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> 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'
>

> On Mon, Jun 11, 2018 at 8:37 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Mon, Jun 11, 2018 at 11:29:49PM +0200, H. Hirzel wrote:
> > >
> > > On 6/11/18, Chris Cunningham <[hidden email]> wrote:
> > >
> > > > On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]>
> > 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