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