On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <stephen at pairhome.net> wrote:

> On Tue, Jun 30, 2009 at 3:00 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>>  But as I've said earlier in the thread the extensional approach has
>> problems when it comes to managing multiple packages that can overlap (as I
>> think s inevitable in imperfect complex systems).
>>
>
> I realize this thread is more concerned with the here and the now, but
> doesn't this problem go away entirely in a system like Newspeak?  When you
> can have modules of code co-resident and active at the same time, wouldn't
> you just create a new version of some package on which you depend rather
> than patch it with extension methods you define in your own package?  Your
> code would happily use your version of the package while others happily use
> the unmodified version.
>

In theory yes.  But as soon as one had a living system which contained
objects already active then I don't see how the Newspeak module system
solves the problem.  It neatly allows one to reuse modules and extend them
locally.  But as far as I can see once you want to interact in new ways with
already live objects then one may still need to patch.

Gilad is virulently against monkey-patching and so there is no support for
extensions in Newspeak modules; all very well.  But at the same time one of
the models of use for Newspeak is where clients implemented in Newspeak are
orthogonally synchronised (both data and code are updated) at suitable
points in an applications' use (e.g. when a server interaction is
initiated).  Here the author of a module is allowed to modify it and the
next time any client containing an instance of that module would have the
client's instance of the module updated transparently.  So in a situation
where some rich application on the client is composed of two modules, and
the author of one of them wants an extension method added to the other so
that his modifications can function one would have to request the author of
the other module to add it and (presumably) wait for changes to propagate.
 There are lots of issues here (what if the author of the second module goes
bust) but if the picture can be realised its actually much better than the
Smalltalk package status quo because every instance is continuously
integrated.  One of the issues that gives rise to the need for patches is
that one can't ask the author to update their package and so one has to do
it oneself.  Gilad's scheme is a great idea, but I'm not entirely sure it is
that different from the current situation with automatically updated
software (OSs etc).  As the software gets more complex so organizations are
less able to change it frequently.  Newspeak may have some new means with
which to attack the problem but the problem still remains.

 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 :)



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