Browser (and categories) question

> Hi list,
>         even though I've been using Store for a while (following the
> basic guidelines about organizing code in Bundles and Packages) I must
> admit I'm no expert, so i apologize in advance if I'm missing something.
>
> Most of the time I want to organize my classes, extensions, etc. in
> categories. Those categories would look pretty much like packages,
> except for two things:
>
> 1. I don't want to see them in the "Published Items" dialog nor to be
> able to load them independently. So, if package A has two categories
> C1 and C2, I would only see A in the "Published Items".
>
> 2. No requisite relationships between categories (e.g. I would like to
> have circular class references between C1 and C2 without getting
> warnings when loading the package).
>
> So, in other words, I would like to have a way to organize (logically)
> the code inside a package, so that it is easy (at least for me :)) to
> manage while keeping the package indivisible. Is there such a thing?
> Any ideas or suggestions?
>
> Thanks in advance!
>
> Andrés
>
>

> Give Travis's PackageFragments a go - they are not entirely finished,
> but they seem to work. Feedback is obviously welcome. It adds
> 'fragments' inside of packages for your classes, namespaces, extensions,
> etc.
>
> Andres Fortier wrote:
>> Hi list,
>>         even though I've been using Store for a while (following the
>> basic guidelines about organizing code in Bundles and Packages) I must
>> admit I'm no expert, so i apologize in advance if I'm missing something.
>>
>> Most of the time I want to organize my classes, extensions, etc. in
>> categories. Those categories would look pretty much like packages,
>> except for two things:
>>
>> 1. I don't want to see them in the "Published Items" dialog nor to be
>> able to load them independently. So, if package A has two categories
>> C1 and C2, I would only see A in the "Published Items".
>>
>> 2. No requisite relationships between categories (e.g. I would like to
>> have circular class references between C1 and C2 without getting
>> warnings when loading the package).
>>
>> So, in other words, I would like to have a way to organize (logically)
>> the code inside a package, so that it is easy (at least for me :)) to
>> manage while keeping the package indivisible. Is there such a thing?
>> Any ideas or suggestions?
>>
>> Thanks in advance!
>>
>> Andrés
>>
>>
>
>

> You should always organize our code into components. By "component" I
> mean a set of classes and methods (possibly extensions) that add some
> meaningful behavior/functionality to the system. Any component should
> be loadable and functional when its prerequisites are loaded.
>
> The paper "Design Principles and Design Patterns" discusses why making
> software out of components is important:
> http://www.objectmentor.com/omReports/articles/Principles_and_Patterns.pdf
>
> In Store, the "package" is the natural choice for representing a
> component. I strongly believe the package should function as the
> "component", and not a way to categorize code. If used for
> categorization, the package is unlikely to contain a meaningful
> extension to the system. You will need to load other categories
> (packages) to make up a complete component and the result is (like you
> discovered), circular dependencies between packages.
>
> I have written about this topic on my blog. Some of the posts which
> cover this includes:
> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Starting_to_Organize_Classes_in_Packages&entry=3277642013 
>
> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Envy_to_Store:_Verifying_Prerequisites&entry=3260743764 
>
> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Naming_Bundles_and_Packages&entry=3257163245 
>
>
> I also discuss Fragments here:
> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Fragments_For_Store&entry=3269120743 
>
> Fragments are not integrated into the standard tools, and I do not
> think this add-on is enhanced and supported. The idea is great, and
> the author now works with tools in Cincom Smalltalk, so I hope we
> someday will see a version integrated into the standard tools.
>
> Right now I think we have to live with packages being a huge pile of
> classes. It is better to accept this, than start using packages to
> categorize code.
>
> Kind regards
> Runar Jordahl
>

>
>
> On 7/2/07, *Andres Fortier* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Runar,
>               I agree with what you said about packages as being
>     components
>     and not using them to categorize code. The thing is that, having no
>     other standard way (at least that I know) of categorizing code, it is
>     easy to end up by using bundles as packages and packages as
>     categories.
>
>
>
> In the good old days there used to be categories ;)
>
>
>     -specially when you are new to store-. I'm giving a try to
>     PackageFragments, hopefully they will solve some of these issues.
>
>     Best Regards (and thanks for the links!)
>
>     andrés
>
>     Runar Jordahl escribió:
>     > You should always organize our code into components. By
>     "component" I
>     > mean a set of classes and methods (possibly extensions) that add
>     some
>     > meaningful behavior/functionality to the system. Any component
>     should
>     > be loadable and functional when its prerequisites are loaded.
>     >
>     > The paper "Design Principles and Design Patterns" discusses why
>     making
>     > software out of components is important:
>     >
>     http://www.objectmentor.com/omReports/articles/Principles_and_Patterns.pdf
>     >
>     > In Store, the "package" is the natural choice for representing a
>     > component. I strongly believe the package should function as the
>     > "component", and not a way to categorize code. If used for
>     > categorization, the package is unlikely to contain a meaningful
>     > extension to the system. You will need to load other categories
>     > (packages) to make up a complete component and the result is
>     (like you
>     > discovered), circular dependencies between packages.
>     >
>     > I have written about this topic on my blog. Some of the posts which
>     > cover this includes:
>     >
>     http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Starting_to_Organize_Classes_in_Packages&entry=3277642013
>     <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Starting_to_Organize_Classes_in_Packages&entry=3277642013>
>     >
>     >
>     http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Envy_to_Store:_Verifying_Prerequisites&entry=3260743764
>     <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Envy_to_Store:_Verifying_Prerequisites&entry=3260743764>
>     >
>     >
>     http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Naming_Bundles_and_Packages&entry=3257163245
>     <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Naming_Bundles_and_Packages&entry=3257163245>
>     >
>     >
>     > I also discuss Fragments here:
>     >
>     http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Fragments_For_Store&entry=3269120743
>     <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Fragments_For_Store&entry=3269120743>
>     >
>     > Fragments are not integrated into the standard tools, and I do not
>     > think this add-on is enhanced and supported. The idea is great, and
>     > the author now works with tools in Cincom Smalltalk, so I hope we
>     > someday will see a version integrated into the standard tools.
>     >
>     > Right now I think we have to live with packages being a huge pile of
>     > classes. It is better to accept this, than start using packages to
>     > categorize code.
>     >
>     > Kind regards
>     > Runar Jordahl
>     >
>
>

> Dear Andres, Eliot et al,
>
> Eliot Miranda wrote:
>  > In the good old days there used to be categories ;)
>
> Although categories are now deprecated, all the code is still there to
> categorise classes, shared variables and bindings in general, and it is
> easy to restore the category browser as a third option in the RB,
> alongside packages and parcels.
>
> However as Andres includes extension methods in his list of things he
> wants to categorize, I'm guessing the old category concept is not what
> he wants, unless he is prepared to extend it somewhat.  I have written
> utilities to improve category-namespace interactions (which gave me a
> good insight into why VW, after introducing namespaces, began to
> deprecate categories :-)) but giving an extension method a category
> distinct from that of its class would be something else again.
>
> Since categories are deprecated, Andres might also find the code
> vanishes from under him at some future time.
>
> So, if PackageFragments works fine for you, Andres, that is probably
> best.  If not, you could attempt to exploit categories, noting the
> problems listed above.
>
>          Yours faithfully
>             Niall Ross
>
>>
>>
>> On 7/2/07, *Andres Fortier* <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Hi Runar,
>>               I agree with what you said about packages as being
>>     components
>>     and not using them to categorize code. The thing is that, having no
>>     other standard way (at least that I know) of categorizing code, it is
>>     easy to end up by using bundles as packages and packages as
>>     categories.
>>
>>
>>
>> In the good old days there used to be categories ;)
>>
>>
>>     -specially when you are new to store-. I'm giving a try to
>>     PackageFragments, hopefully they will solve some of these issues.
>>
>>     Best Regards (and thanks for the links!)
>>
>>     andrés
>>
>>     Runar Jordahl escribió:
>>     > You should always organize our code into components. By
>>     "component" I
>>     > mean a set of classes and methods (possibly extensions) that add
>>     some
>>     > meaningful behavior/functionality to the system. Any component
>>     should
>>     > be loadable and functional when its prerequisites are loaded.
>>     >
>>     > The paper "Design Principles and Design Patterns" discusses why
>>     making
>>     > software out of components is important:
>>     >
>>    
>> http://www.objectmentor.com/omReports/articles/Principles_and_Patterns.pdf 
>>
>>     >
>>     > In Store, the "package" is the natural choice for representing a
>>     > component. I strongly believe the package should function as the
>>     > "component", and not a way to categorize code. If used for
>>     > categorization, the package is unlikely to contain a meaningful
>>     > extension to the system. You will need to load other categories
>>     > (packages) to make up a complete component and the result is
>>     (like you
>>     > discovered), circular dependencies between packages.
>>     >
>>     > I have written about this topic on my blog. Some of the posts which
>>     > cover this includes:
>>     >
>>    
>> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Starting_to_Organize_Classes_in_Packages&entry=3277642013 
>>
>>    
>> <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Starting_to_Organize_Classes_in_Packages&entry=3277642013>
>>
>>     >
>>     >
>>    
>> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Envy_to_Store:_Verifying_Prerequisites&entry=3260743764 
>>
>>    
>> <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Envy_to_Store:_Verifying_Prerequisites&entry=3260743764>
>>
>>     >
>>     >
>>    
>> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Naming_Bundles_and_Packages&entry=3257163245 
>>
>>    
>> <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Naming_Bundles_and_Packages&entry=3257163245>
>>
>>     >
>>     >
>>     > I also discuss Fragments here:
>>     >
>>    
>> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Fragments_For_Store&entry=3269120743 
>>
>>    
>> <http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Fragments_For_Store&entry=3269120743>
>>
>>     >
>>     > Fragments are not integrated into the standard tools, and I do not
>>     > think this add-on is enhanced and supported. The idea is great, and
>>     > the author now works with tools in Cincom Smalltalk, so I hope we
>>     > someday will see a version integrated into the standard tools.
>>     >
>>     > Right now I think we have to live with packages being a huge
>> pile of
>>     > classes. It is better to accept this, than start using packages to
>>     > categorize code.
>>     >
>>     > Kind regards
>>     > Runar Jordahl
>>     >
>>
>>
>
>
>
>