On Wed, Jul 1, 2009 at 12:18 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
> 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.
>

LoL...well, of course...if the problem were already solved, there would be
no point in contemplating possible solutions.


>   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.
>

Didn't someone once say that the operating system is where you resolve all
of the inadequacies of your language (or something to that effect)?  ;)


> 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.
>

I don't think you need to go to such lengths to either show that such a
scheme would work, or to get use out of it if it does.  Regarding your
iPhone example, it takes the discussion beyond the realm of that which we
have control and into the realm of interfacing with legacy systems in which
none of these kinds of issues have been considered or addressed.  Take and
example of upgrading the AddressBook on the iPhone platform (where it's a
third party tool over which you have no control other than to upgrade it)
while having it still work with say a custom Dialer app that you wrote.  You
are free to upgrade either of them independently so long as they both
support a common interface.  If the interface were version controlled, you
can deal with this problem in a pretty rational manner for an end user (when
you go to the AppStore and try to upgrade the AddressBook app, it could
alert you that "this new version of the AddressBook no longer supports
version 1 of the AddressBook API and since we see that you have a registered
dependency form some Dialer app on version 1.0, we can pretty much guarantee
that it's going to break your Dialer app, are you sure you want to do this?"
 You could then independently upgrade the Dialer app.

To bring this back to monkey patching...no, you cannot monkey patch the
AddressBook API, but you can create a new version of some framework (with as
many customizations as you desire) for use in your Dialer app while the,
while the AddressBook continues to use some other version of that very same
framework concurrently.  Of course, Cocoa is not going to support this kind
of thing (at least not today), but it doesn't preclude apps in some other
language that has Newspeak style modularization from doing this (regardless
of whether it's running on bare metal or not).

I think I've run out of steam on this topic for now.

- Stephen

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090701/cd18a670/attachment.htm