[Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?
BasicClassOrganizer has no users... Is it there for any purpose? What about joining them? Guille
On 6 April 2012 16:53, Guillermo Polito <guillermopolito@gmail.com> wrote:
BasicClassOrganizer has no users... Is it there for any purpose?
What about joining them?
Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space.. I would rewrite this stuff and leave just a Categorizer with clean protocol and structure: - categorizer holds categories (order could be important, but i would just keep it unspecified , i.e, instead OrderedCollection ( categoryName -> {.. category items .. } ) I would use Dictionary #categoryName -> Set(items) this class should serve basic operations like adding /removing and queries: - what is a categor(ies) of element (if element can be include only into single category at once) - what are category names - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages). The way how BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp. Class organizer, should instead delegate, or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess.
Guille
-- Best regards, Igor Stasenko.
On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2012 16:53, Guillermo Polito <guillermopolito@gmail.com> wrote:
BasicClassOrganizer has no users... Is it there for any purpose?
What about joining them?
Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space..
I would rewrite this stuff and leave just a Categorizer with clean protocol and structure:
yes - categorizer holds categories (order could be important, but i would
just keep it unspecified , i.e,
yes. I was working in a simple version having #sort:, #sortAlphabetically, #sortByAmmountOfElements
instead OrderedCollection ( categoryName -> {.. category items .. } )
I would use Dictionary #categoryName -> Set(items)
I'd like having a Category object there.
this class should serve basic operations like adding /removing and queries: - what is a categor(ies) of element (if element can be include only into single category at once) - what are category names - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages).
but then we have to put the changes announcements/notifications in another place
The way how BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp.
Ok, you are making me open an issue to move those to class :). 1.5?
Class organizer, should instead delegate, or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess.
Guille
-- Best regards, Igor Stasenko.
On Fri, Apr 6, 2012 at 8:07 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:
On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2012 16:53, Guillermo Polito <guillermopolito@gmail.com> wrote:
BasicClassOrganizer has no users... Is it there for any purpose?
What about joining them?
Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space..
I would rewrite this stuff and leave just a Categorizer with clean protocol and structure:
yes
- categorizer holds categories (order could be important, but i would
just keep it unspecified , i.e,
yes. I was working in a simple version having #sort:, #sortAlphabetically, #sortByAmmountOfElements
instead OrderedCollection ( categoryName -> {.. category items .. } )
I would use Dictionary #categoryName -> Set(items)
I'd like having a Category object there.
this class should serve basic operations like adding /removing and queries: - what is a categor(ies) of element (if element can be include only into single category at once) - what are category names - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages).
but then we have to put the changes announcements/notifications in another place
The way how BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp.
Ok, you are making me open an issue to move those to class :). 1.5?
I'm having a warning telling me class should not be redefined when doing | classCommentVarName commentStampVarName | classCommentVarName := 'classComment' capitalized. commentStampVarName := 'commentStamp' capitalized. Class addInstVarNamed: classCommentVarName. Class addInstVarNamed: commentStampVarName. ProtoObject allSubclassesDo: [ :c | c instVarNamed: classCommentVarName put: (c organization classComment). c instVarNamed: commentStampVarName put: (c organization commentStamp) ]. But proceeding takes a while but seems to work... Any special reason to not adding inst vars to Class?
Class organizer, should instead delegate, or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess.
Guille
-- Best regards, Igor Stasenko.
On 6 April 2012 20:07, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2012 16:53, Guillermo Polito <guillermopolito@gmail.com> wrote:
BasicClassOrganizer has no users... Is it there for any purpose?
What about joining them?
Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space..
I would rewrite this stuff and leave just a Categorizer with clean protocol and structure:
yes
 - categorizer holds categories (order could be important, but i would just keep it unspecified , i.e,
yes. I was working in a simple version having #sort:, #sortAlphabetically, #sortByAmmountOfElements
instead  OrderedCollection ( categoryName -> {.. category items .. } )
I would use Dictionary #categoryName -> Set(items)
I'd like having a Category object there.
this class should serve basic operations like adding /removing and queries:  - what is a categor(ies) of element (if element can be include only into single category at once)  - what are category names  - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages).
but then we have to put the changes announcements/notifications in another place
yes. of course. usually operations are logged by separate entity than in place where it actually happens. you recording some operation over some model, and model don't necessary needs to know that you recording, isn't?
The way how  BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp.
Ok, you are making me open an issue to move those to class :). 1.5?
Class organizer, should instead delegate, Â or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess.
Guille
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Fri, Apr 6, 2012 at 10:30 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2012 20:07, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 6 April 2012 16:53, Guillermo Polito <guillermopolito@gmail.com>
wrote:
BasicClassOrganizer has no users... Is it there for any purpose?
What about joining them?
Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space..
I would rewrite this stuff and leave just a Categorizer with clean protocol and structure:
yes
- categorizer holds categories (order could be important, but i would just keep it unspecified , i.e,
yes. I was working in a simple version having #sort:, #sortAlphabetically, #sortByAmmountOfElements
instead OrderedCollection ( categoryName -> {.. category items .. } )
I would use Dictionary #categoryName -> Set(items)
I'd like having a Category object there.
this class should serve basic operations like adding /removing and queries: - what is a categor(ies) of element (if element can be include only into single category at once) - what are category names - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages).
but then we have to put the changes announcements/notifications in another place
yes. of course. usually operations are logged by separate entity than in place where it actually happens. you recording some operation over some model, and model don't necessary needs to know that you recording, isn't?
I'm with you :), was just remarking one implication of the change. And thinking that way makes the change much more aggressive :P. But I know, step by step...
The way how BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp.
Ok, you are making me open an issue to move those to class :). 1.5?
Class organizer, should instead delegate, or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess.
Guille
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Ideally I want to remove categories because they are redundant with package and they should be managed as class tags.
On Fri, Apr 6, 2012 at 10:30 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 6 April 2012 20:07, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2012 16:53, Guillermo Polito <guillermopolito@gmail.com> wrote:
BasicClassOrganizer has no users... Is it there for any purpose?
What about joining them?
Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space..
I would rewrite this stuff and leave just a Categorizer with clean protocol and structure:
yes
- categorizer holds categories (order could be important, but i would just keep it unspecified , i.e,
yes. I was working in a simple version having #sort:, #sortAlphabetically, #sortByAmmountOfElements
instead OrderedCollection ( categoryName -> {.. category items .. } )
I would use Dictionary #categoryName -> Set(items)
I'd like having a Category object there.
this class should serve basic operations like adding /removing and queries: - what is a categor(ies) of element (if element can be include only into single category at once) - what are category names - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages).
but then we have to put the changes announcements/notifications in another place
yes. of course. usually operations are logged by separate entity than in place where it actually happens. you recording some operation over some model, and model don't necessary needs to know that you recording, isn't?
I'm with you :), was just remarking one implication of the change. And thinking that way makes the change much more aggressive :P. But I know, step by step...
The way how BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp.
Ok, you are making me open an issue to move those to class :). 1.5?
Class organizer, should instead delegate, or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess.
Guille
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (4)
-
Craig Latta -
Guillermo Polito -
Igor Stasenko -
Stéphane Ducasse