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)).
 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090630/7486e5b4/attachment.htm