2008/6/28 Damien Pollet <[hidden email]>:
> Ex. Pier needs Seaside. If there is a new release of Pier, the Pier > developers update the Pier package and nothing more. If Seaside gets > upgraded, the Pier package should *not* have to change/be > regenerated/whatever until the Pier code is updated. > This scenario is quite unlikely in Squeak , but surely it is possible in general in smalltalk (Spoon addresses that, getting rid of globals addresses that :) Once you change a class from which depends the rest, it may require to update dependent code as well, otherwise it will be broken. Unless people design things with modularity in mind, but i don't see many of such packages, which can be used w/o fear that updating them will not break something else. This is a real main problem of squeak: bad design which prohibits modularity, not MC or SqueakMap nor CPAN or other tools. First, we need a paradigm shift IMO. From solid, single image where everything is closely tied, to modular system where different parts does not interfere with others, or if interfere, they play by strict rules. We had a lengthly battle yesterday on #squeak IRC channel. It seems everyone wants better Squeak as we know it. But having different views on it. Surely, we can improve our tools, and they indeed need improvement. This is great, but in the end, if we stay with old paradigm, no wonder will happen. Ask yourself, do you want a system, where you can load any code without any risk, and even if it broken, it will not break the rest of your system? Do we want it to be a smalltalk, not a NewSpeak? Or we just wait till NewSpeak (or another heir of smalltalk will successed and migrate to it?). Lets just understand, that to get to new level, we need a quality shift (change system to become truly modular) , not quantity (make more or better tools). Only after we do that, squeak can explode with quantity, because there will be much less things to deal with. As with Alan's analogy: we have objects which behave as body cells and they are quite modular. But why, at same time, we deny that group of cells (package/set of classes) can't be modular? Make system modular. This is what most of currently elected board members (including me) had in their platform. This is what, i think people wanted from us. -- Best regards, Igor Stasenko AKA sig. |
On Sat, Jun 28, 2008 at 11:01 PM, Igor Stasenko <[hidden email]> wrote:
> Once you change a class from which depends the rest, it may require to > update dependent code as well, otherwise it will be broken. Yeah but that's not the fault of the package system then, it's poor development practice as you say. > First, we need a paradigm shift IMO. From solid, single image where > everything is closely tied, to modular system where different parts > does not interfere with others, or if interfere, they play by strict > rules. This is a chicken/egg problem as usual. IMHO if we have a package system then users will try to upgrade things more often (revealing bugs faster) and developers will have something to document dependancies in a practical way. That's also why I'd like to see the package layer integrated with squeaksource eventually, to make it simple to update a package (with metadata integrated in MC snapshots for instance). -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet |
In reply to this post by Igor Stasenko
On Sun, Jun 29, 2008 at 9:01 AM, Igor Stasenko <[hidden email]> wrote:
I'm working on it... ;-). http://gulik.pbwiki.com/SecureSqueak Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ |
Free forum by Nabble | Edit this page |