On Wed, Jul 1, 2009 at 10:12 AM, Stephen Pair <stephen at pairhome.net> wrote:

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

Hi Stephen,
   apologies for apparently being obstructive.  I was just trying to
properly frame the discussion.  I want to separate linguistic from system
issues.  Your first question was an excellent one
and asked if linguistic mechanisms could resolve the issue and I said why I
thought not.  I didn't realise you were shifting ground to propose solutions
and thought you were still discussing linguistic mechanisms.  Apologies.
 Please don't run out of steam because I'm not going with the flow.  I hope
I get where you're aiming at now.


Could you extend your scenario with the potential for malware to attempt to
patch the AddressBook and suggest ways one can legitimately patch the
AddressBook and at the same time protect it from unwarranted modification?


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