[squeak-dev] Future of Squeak, and outsider's view

2009/6/30 Cameron Sanders <[hidden email]>:

> What you write (down below) is close to what I was thinking when I said have
> all #isXXX return false by default;
> although I would test that the first two characters match 'i' and 's' and
> that more characters exist, if so, return false, otherwise, normal
> #doesNotUnderstand: behavior.
>
> I would treat #is by itself differently... it is ... or it couldn't be
> tested! So I would do nothing for simple #is. and I don't like #is: because
> it looks like a class type test... but that is part of the point, eh?
>

I wouldn't say that. It is more trait-based approach than class-based.

The concept of #is: are: When object foo having some trait, it should
answer true on 'foo is: sometrait ', otherwise false.
Obviously since most subclasses inherit the behavior & traits of base
class, you should honor this rule in overrides of #is: method
i.e.:

Someclass>>is: object
 ^ (your tests here) or: [ super is: object ]

otherwise, if you omit the super send, some of the traits will become
unavailable. But of course, except when you doing this intentionally.

> I'll have to go back to the original example (by [hidden email], and
> read more about lambdas) but I thought that CVLambda would implement
> #isCVLambda  to return true when it can be verified to be one. The example
> did not illustrate #doesNotUnderstand:.
>
> Back to the question of adding behavior to classes that you don't own.
> VisualWorks has a means to extend a class in a different package ... as I
> recall. As I recall, squeak has no such capability, right?
>

MC having this capability for a years.

> Thanks. You have given me food for thought...
>
> Ciao,
> Cam
>
> On Jun 29, 2009, at 3:43 PM, David Goehrig wrote:
>
>> What I typically what I've been doing to eliminate all of these methods
>> with a single simple change:
>>
>> Object
>>   doesNoUnderstand: aMessage
>>       ^ false
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

2009/6/30 Eliot Miranda <[hidden email]>:

>
>
> On Mon, Jun 29, 2009 at 8:59 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> 2009/6/30 Cameron Sanders <[hidden email]>:
>> > What you write (down below) is close to what I was thinking when I said
>> > have
>> > all #isXXX return false by default;
>> > although I would test that the first two characters match 'i' and 's'
>> > and
>> > that more characters exist, if so, return false, otherwise, normal
>> > #doesNotUnderstand: behavior.
>> >
>> > I would treat #is by itself differently... it is ... or it couldn't be
>> > tested! So I would do nothing for simple #is. and I don't like #is:
>> > because
>> > it looks like a class type test... but that is part of the point, eh?
>> >
>>
>> I wouldn't say that. It is more trait-based approach than class-based.
>>
>> The concept of #is: are: When object foo having some trait, it should
>> answer true on 'foo is: sometrait ', otherwise false.
>> Obviously since most subclasses inherit the behavior & traits of base
>> class, you should honor this rule in overrides of #is: method
>> i.e.:
>>
>> Someclass>>is: object
>>  ^ (your tests here) or: [ super is: object ]
>>
>> otherwise, if you omit the super send, some of the traits will become
>> unavailable. But of course, except when you doing this intentionally.
>>
>>
>> > I'll have to go back to the original example (by [hidden email], and
>> > read more about lambdas) but I thought that CVLambda would implement
>> > #isCVLambda  to return true when it can be verified to be one. The
>> > example
>> > did not illustrate #doesNotUnderstand:.
>> >
>> > Back to the question of adding behavior to classes that you don't own.
>> > VisualWorks has a means to extend a class in a different package ... as
>> > I
>> > recall. As I recall, squeak has no such capability, right?
>> >
>>
>> MC having this capability for a years.
>
> Arguably
> not.  (BTW VW has had it from 98).  The crucial difference is that in
> VW an extension can be in more than one package.  In Squeak a selector can
> only be in a single Monticello extension category.  That leads to the awful
> bug that when an MC package patches a base selector to extend it to fix a
> bug it ends up in the package and its membership of the package it was in
> previously being lost.  I understand that with method history this situation
> can be detected but if you e.g. condense changes then that history is lost,
> and the base package selector becomes only an extension  Ouch.
> The VW "solution" is OK as far as it goes; a package is a set of class,
> selector pairs (more than this, but this is the essence).  An MC package is
> defined by class and method categories.  VW's parcels are intensional, MC
> packages are extensional.  There's a tension in both; many VW'ers want, at
> least at the UI level, for packages to be extensional, but precision
> (knowing whether something is in a package or not, allowing things to be in
> more than one package so that one can include patches, etc) requires an
> intentional construct.
> When you also provide selector namespaces I don't think the situation
> changes because one still needs patches in the absence of a perfectly
> designed system.  So IMO somehow MC needs to move to an intensional package
> definition, at least for extensions ;)
>

i just wanted to point that MC having an extension mechanism. Yes, it
is different from VW one.
And in the light of your description - it is done wrong (at least for
me), but its still can be called 'extension mechanism' :)

>>
>>
>> > Thanks. You have given me food for thought...
>> >
>> > Ciao,
>> > Cam
>> >
>> > On Jun 29, 2009, at 3:43 PM, David Goehrig wrote:
>> >
>> >> What I typically what I've been doing to eliminate all of these methods
>> >> with a single simple change:
>> >>
>> >> Object
>> >>   doesNoUnderstand: aMessage
>> >>       ^ false
>> >
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>
>

--

Best regards,
Igor Stasenko AKA sig.

Eliot Miranda wrote:

Arguably not.  (BTW VW has had it from 98).  The crucial difference is that
in VW an extension can be in more than one package.  In Squeak a selector can only be in a single Monticello extension category.  That leads to the awful bug that when an MC package patches a base selector to extend it to fix a bug it ends up in the package and its membership of the package it was in previously being lost.  I understand that with method history this situation can be detected but if you e.g. condense changes then that history is lost, and the base package selector becomes only an extension  Ouch.

That's a bug in condenseChanges, not a conceptual problem. BTW, I really fail to see how it would make any difference whatsoever if extension methods are in multiple packages or not. In either case you are *completely* screwed if you have multiple packages trying to extend the same method. Seriously, has there ever been a situation where that actually works? (my personal preference is actually that MC should blow up straight into your face if you try to change a method that's in an extension category already, but that's just me - I generally avoid extensions like the plague)

The VW "solution" is OK as far as it goes; a package is a set of class, selector pairs (more than this, but this is the essence).  An MC package is defined by class and method categories.  VW's parcels are intensional, MC packages are extensional.

I don't understand the distinction you are making between intensional and extensional. Care to elaborate?

MC internally actually uses a set of class and selector pairs as well, it just derives them via PackageInfo from categories. And it most certainly can have methods in multiple packages. For example, if you add a method in category '*Foo-Bar-Baz' it will be part of the packages 'Foo-Bar-Baz', 'Foo-Bar' and 'Foo' (if those exist).

The only thing that prevents you from having other combinations of multiple package memberships is that there is no UI that allows you to specify which combinations of packages a method should be part of. The category hack is great because it works with existing tools, but existing tools don't allow for methods in multiple categories. If you fix that you get your multiple package membership in Monticello for free. Alternatively provide a UI to specify which other packages the method should be part of, and you're there, too.

Cheers,
 - Andreas

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

On Tue, Jun 30, 2009 at 3:00 PM, Eliot Miranda <[hidden email]> 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.

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

- Stephen 

On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <[hidden email]> 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 :)

Eliot Miranda wrote:

On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <[hidden email] <mailto:[hidden email]>> wrote:

   ...

   I really fail to see how it would make any difference whatsoever
   if extension methods are in multiple packages or not. In either
   case you are *completely* screwed if you have multiple packages
   trying to extend the same method. Seriously, has there ever been a
   situation where that actually works? (my personal preference is
   actually that MC should blow up straight into your face if you try
   to change a method that's in an extension category already, but
   that's just me - I generally avoid extensions like the plague)


I don't avoid extensions, and personally feel extensions are a core part of building frameworks.  If objects are to interact they must provide protocol to support that interaction.  In adding a new framework to an existing system this means extending existing objects so that they can interact with the new framework.  Yes, one can do this badly, but there are lots of examples where this makes sense.

As far as patching, we've had this conversation before.  I agree that a well-designed system will provide extension mechanisms that make patching unnecessary.

And later...

Gilad is virulently against monkey-patching and so there is no support for extensions in Newspeak modules...

Extension methods are useful, but can be dangerous. Problems will arise if a module modifies the behavior that is expected by the base system or by other modules that do not include us as a prerequisite.

Things a module should not be able to do to existing classes (defined in the base system or in other modules)
- patching: modify existing methods, including any extensions done by other modules
- add new methods that redefine inherited behavior (I mean, a method not already implemented but inherited)
- delete any method

Things a module should be able to do:
- extend existing classes with new methods that do not affect the base system or any other module that does not include us as a prerequisite

An easy way to ensure this is to require each module to define a prefix for its extension methods. The system must ensure that the prefixes are distinct for all modules, and that a prefix can be used only by its owning module to define new methods. The base system can not use any of those prefixes. A module can call a prefixed method only if it owns it, or it belongs to some other module that was declared as a prerequisite.

It is sort of cheap namespaces for methods (not for classes).

What do you think?

Cheers,
Juan Vuletich

On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <[hidden email]> 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

On Tue, Jun 30, 2009 at 6:15 PM, Stephen Pair <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <[hidden email]> 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.