1 Jul 2009 18:18
Re: Re: Future of Squeak, and outsider's view
Eliot Miranda <eliot.miranda <at> gmail.com>
2009-07-01 16:18:05 GMT
2009-07-01 16:18:05 GMT
On Tue, Jun 30, 2009 at 6:15 PM, Stephen Pair <stephen <at> pairhome.net> wrote:
On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <eliot.miranda <at> gmail.com> wrote:On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <stephen <at> pairhome.net> wrote:I can see a potential need in cases where a body of code is designed to interface with some already present service (for example, a phone dialer application designed to use an AddressBook service). But, in such a system, you wouldn't want to allow monkey patching anyway out of security concerns (if you could override the AddressBook interface, your code could potentially access information that the owner didn't want your code to access).But how do you override your own AddressBook? Bringing a new one into existence is one thing, but modifying your fully-populated one implemented by someone else is another thing altogether. If the system is so architected then it is presumably trivial to create a new instance, move the data across and replace the old with the new. But if the system isn't (e.g. for security or ip concerns) then you can't. But these issues operate at a higher level than the language/module/update level right? The issues with monkey patching are to do with keeping software maintainable and comprehensible to software authors. The issues of mutable extensible systems also involve their users, and that's more than I can think about right now :)Overriding your own AddressBook would be a problem of loading in new code and migrating the instances (pretty much like software works today where you load a new version of an application and it has to update your existing database(s)).
That's a fine scheme. My point is that unless the system is so architected you can't necessarily do that. Look at the iPhone for example; there are lots of restrictions on what a user can accomplish and there is software therein to detect attempts to hack around these restrictions and break things like software update when you try and update a hacked phone. So your model only works in an architecture which supports it. Since Newspeak doesn't encompass a complete device architecture it can't provide an update schema for it. Expecting a language to address this is IMO a category error. When one starts talking about for example a Smalltalk system running on bare hardware (e.g. Squeak NOS) then the system can encompass the entirety. So we should first try and evolve Newspeak to NewspeakNOS and ten we can see how an evolved NewspeakNOS would address these update issues.
So, the new code would have whatever fancy new stuff you wanted to do in your AddressBook, but for external applications like the phone dialer to be able to interact with it, it would still need support some defined (and ideally versioned) interface. To the degree that new versions of the phone dialer and the address book are backward compatible with the versions of the interface they support, you are free to upgrade each independently. And, the AddressBook is free to use some highly customized collections framework while the phone dialer uses an entirely different implementation of collections. Such a system would offer very significant benefits to a community like squeak. Imagine being able to able to run squeak 2.0 and squeak 3.10 concurrently (with them able to communicate with each other) and imagine all the old, abandoned, but still useful projects that could be readily used without the need to migrate them to all the latest version of your favorite fork. I don't see these issues as being at some higher level, I see the language and platform as lacking a much needed capability.(btw, none of this necessarily implies everything must be in a single process, I imagine much of this could be accomplished using hydra for instance)- Stephen