[Cuis] What gets included in the image vs. external packages

[Juan Vuletich]

Hi Phil,

(big snip, just a few comments)

Phil (list) wrote:
> ...
>> Yes, something like that :) . These are some possible reasons to integrate something in the image:
>> - It belongs in the image conceptually, i.e. it makes sense to integrate it.
>> - It requires some refactoring of image code.
>> - It requires method overrides (method overrides are EVIL, the alternative is to refactor code to avoid them).
>> - It is a very small amount of code, that doesn't add too much complexity, but it simplifies and eases some bigger external package.
>>
>> And these are some possible reasons to keep something as external packages:
>> - The developer(s) want to keep it outside, to have full control.
>> - It is application specific. The Smalltalk system (and dev tools) don't really need it.
>> - There are many alternatives implementations of the functionality, and it is better to let the developer pick one.
>> - It maintained elsewhere (for example, for Squeak, Pharo or some other Smalltalk system), or it is multi-dialect. Avoid code duplication!
>> - It is so complex that the complexity outweighs the usefulness for most people.
>> - It is in alpha state, not stable enough for regular use. (This is to avoid integrating half baked and later abandoned code).
>> - It includes a lot of code that is bad or poorly understood and not maintained.
>>
>> Well, this is what I can think of right now. Maybe you can suggest additions / corrections. After a little discussion, this could go to the Cuis web page.
>>
>>     
>
> This is exactly what I was looking for re: clarity and am in complete agreement with these principles.  I have mixed feelings about formalizing this too much... on the one hand, it addresses my question.  On the other, formally adding it to the web page begins to add a process checklist that probably isn't needed yet.  I'm fine with keeping things relatively fluid and unless this starts to be a concern for other Cuis users, I'd rather not start burdening you or anyone else with what can turn into a bunch of administrative crap and slow things down.
>   

Sounds reasonable... In any case, it is not bad to keep these criteria 
in mind...

> ...
>  In closing, I think what triggered my original post was the excitement re: a lot of the initiatives being talked about raising a red flag in my brain that piling on features might become the new priority at the expense of keeping things small/simple/elegant.  Based on the comments from both of you, the concern appears to have been unwarranted.
>
>   
>
> Thanks,
> Phil
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>   

Thanks for bringing this issues up. I think it is good to talk about 
this things from time to time.

Cheers,
Juan Vuletich