February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions

by Marcus Denker

On Feb 3, 2010, at 5:03 PM, Schwab,Wilhelm K wrote: > Marcus, > > Rats :) You've stolen my thunder. Actually, I won't go as far as to say "never," but I agree. There are places in Squeak that inherit from collections or put methods in Object, and it sure looks as though the programmer didn't know any better. And partly, this was because it was done a very long time ago... back than, it was not known how to program with this newly invented object things. Even by the people who invented it! It's often that others, who than use it, learn how to use it better than the creators. The same will happen with everything we will invent (if we invent anything, that is :-) ). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 3, 2010

Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions

by Schwab,Wilhelm K

Marcus, Rats :) You've stolen my thunder. Actually, I won't go as far as to say "never," but I agree. There are places in Squeak that inherit from collections or put methods in Object, and it sure looks as though the programmer didn't know any better. In fairness, it might have been intended to minimize the chance of runtime errors. Think about it: by wrongly inheriting from OrderedCollection, one is freed from having to delegate its methods (it's not correct, but can seem wise to a beginner or expedient an experienced programmer with poor tools). Mess around with the internals of the user interface, and sliding a method up the hierarchy can avoid a meltdown. These things were all the more true before the days of exception handling. By all means, we should fix these things as we find them. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Wednesday, February 03, 2010 10:53 AM To: Pharo-project(a)lists.gforge.inria.fr Cc: Laval Jannik Subject: Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions On Feb 3, 2010, at 4:43 PM, Mariano Martinez Peck wrote: > > > On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > 4) I have refactored DirectoryEntry to no longer inherit from > ArrayedCollection. Is this an improvement with any community > interest? > > Do you think this is interesting ? What are the benefits of such change ? > > Jannik: do we kill a cycle dependency or something with this change ? > You should never inherit from collections. The problem is that with this, you are depending on the internal working of the collection. Especially objects that model a domain object (like a Directory related thing) should *never* inherit from a collection. Only if you need a special *kind* of collection (technically), it might be interesting to do a subclass of a collection (see MethodDictionary). If you need a collection, you *use* a collection. (you put a standard collection as an instance var). It's very tempting to use inheritance to aquire behavior. But in most cases, it is wrong to use it. You can see this abuse of inheritance very often in Squeak... e.g. Scanner is the superclass of Parser, there are subclasses of SystemWindow (!!), things like that. Bad. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 3, 2010

Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions

by Mariano Martinez Peck

On Wed, Feb 3, 2010 at 4:55 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > Extendability, correctness of semantics, and correctness of > implementation. Inheritance should adhere to an "is-a" relationship; > because it reflects a specialization of the superclass. A > DirectoryEntry is definitely not a Collection.. > > Ahhh I didn't know you were here Chris :) This is cool. Thanks for the explanations. My question was exactly because it come to my mind the example of the MethodDictionary or the one I saw yesterday in VMMaker (Interpreter extends from ObjectMemory). Then yes, we are interested Chris :) I created the issue: http://code.google.com/p/pharo/issues/detail?id=1916 If you can submit the changes, would be really cool. The instructions to do that are here: http://code.google.com/p/pharo/wiki/HowToContribute As far as it is published, it will be integrated in Pharo 1.1. Thank you very much. Mariano > Regards, > Chris > > 2010/2/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller <asqueaker(a)gmail.com> > wrote: > >> > >> 4) I have refactored DirectoryEntry to no longer inherit from > >> ArrayedCollection. Is this an improvement with any community > >> interest? > >> > > > > > > Do you think this is interesting ? What are the benefits of such change > ? > > > > Jannik: do we kill a cycle dependency or something with this change ? > > > > Kind regards, > > > > Mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 3, 2010

Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions

by Chris Muller

Extendability, correctness of semantics, and correctness of implementation. Inheritance should adhere to an "is-a" relationship; because it reflects a specialization of the superclass. A DirectoryEntry is definitely not a Collection.. Regards, Chris 2010/2/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> 4) I have refactored DirectoryEntry to no longer inherit from >> ArrayedCollection. Â Is this an improvement with any community >> interest? >> > > > Do you think this is interesting ?Â Â What are the benefits of such change ? > > Jannik: do we kill a cycle dependency or something with this change ? > > Kind regards, > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 3, 2010

Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions

by Marcus Denker

On Feb 3, 2010, at 4:43 PM, Mariano Martinez Peck wrote: > > > On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > 4) I have refactored DirectoryEntry to no longer inherit from > ArrayedCollection. Is this an improvement with any community > interest? > > Do you think this is interesting ? What are the benefits of such change ? > > Jannik: do we kill a cycle dependency or something with this change ? > You should never inherit from collections. The problem is that with this, you are depending on the internal working of the collection. Especially objects that model a domain object (like a Directory related thing) should *never* inherit from a collection. Only if you need a special *kind* of collection (technically), it might be interesting to do a subclass of a collection (see MethodDictionary). If you need a collection, you *use* a collection. (you put a standard collection as an instance var). It's very tempting to use inheritance to aquire behavior. But in most cases, it is wrong to use it. You can see this abuse of inheritance very often in Squeak... e.g. Scanner is the superclass of Parser, there are subclasses of SystemWindow (!!), things like that. Bad. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 3, 2010

[Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions

by Mariano Martinez Peck

On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > 4) I have refactored DirectoryEntry to no longer inherit from > ArrayedCollection. Is this an improvement with any community > interest? > > Do you think this is interesting ? What are the benefits of such change ? Jannik: do we kill a cycle dependency or something with this change ? Kind regards, Mariano

Feb. 3, 2010

Re: [Pharo-project] What about a "real" research group (was: Do you want to discuss about papers?)

by Serge Stinckwich

2010/2/3 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > I'm ok for such a list... > Nevertheless, I'm wondering if we could go a bit further by doing a kind of > research group with a proper web site listing all people involved and the > projects there're working on.Â We could then establish some categories and > eventually sub-groups. List all published papers, gives ressources to > people... Start simply by discussions on the mailing-list ;-) > We could also have a workshop every year (in ESUG or eventually > independantly). More importantly than discussions on papers, I think we need > to characterise people and their "expertise" area... > For instance, I'm interested in some areas that are not really focussed in > Computer Science problematics (new compiler, traits, etc...). > To me Smalltalk is the vehicle (a fun one) to experiment my research stuffs. > Here are some areas I'm working on: > -Case Based Reasoning - essentially similarity measure with uncertainty > -Constraint Satisfaction Programming (more interested in open models) and > especially the coupling between CBR and CSP > -NARS, a kind of General AI (logical stuff) > -Dynamic open models in general Â ->Â Coevolution of model and their instances > (something I'd really like to dig into) > -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (-> so > as to model expert information) - I would like to apply that to poker game > in the future :) - This is maybe the central aspect of my work > Here is a quick list of what I do or plan to do...Â Having a central web site > would be excellent for visibility (of course a mailing can be setup too), > both for Smalltalk and for people doing research with it. > What others think ? I'm also interested by representing uncertainty and probabilistic programming mainly for robotic applications. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Feb. 3, 2010

Re: [Pharo-project] Questions about ToolSet

by StÃ©phane Ducasse

On Feb 3, 2010, at 12:00 AM, Mariano Martinez Peck wrote: > Hi folks. I found I big problem with the way ToolSet works or at least with the way I think it works. Right now, there is the class ToolSet with certain methods like API and then a class side method to register a XXX ToolSet as default. So, we have for example, the StandardToolSet which implements/overrides some of the methods of ToolSet. Of course, that ToolSet (StandardToolSet) is the default. Evaluate ToolSet default and you will get that one. Becuase that is done is StandardToolSet class >> initialize > > Now...the first question, why StandardToolSet doesn't extend from ToolSet ? shouldn't that be better ? Apparently what you want is a kind of factory ToolSet is a facade StandardToolSet is an adaptor making the glue between the protocol of ToolSet and the actual tools. So delegation is not that bad. now by adding a inheritance relationship we could reuse default code when possible. inspectorClassOf: anObject "Answer the inspector class for the given object. The tool set must know which inspector type to use for which object - the object cannot possibly know what kind of inspectors the toolset provides." self default ifNil:[^nil]. ^self default inspectorClassOf: anObject the self default ifNil: [^nil] looks also suspicious. > I don't like the name WorkspaceClassName, we should look for better names > Then, I can just have a post do it when loading Shout that evaluates: > > (Smalltalk at: #WorkspaceClassName put: SHWorkspace) I like the suggestion of doru. ToolSet should have a way to registering new tools to specific protocol and that you can access and change a given set. One of the problem is that it can be easy if all the tools kind (all debuggers) agree to follow the same interface to get opened.... Stef

Feb. 3, 2010

Re: [Pharo-project] Fwd: Communicating Event Loops

by StÃ©phane Ducasse

> >> Igor >> >> You know Concurrent Smalltalk was certainly like that too. >> Now my point is that this is good to share ideas that there are old or not. >> Already discussed or not. > > Yes, that's why i asked , because i didn't understood your message. So I repeat it. Right now on my desktop when I open any Smalltalk I still have some old ideas moving inside. And we would like to create a different world in which even old ideas that were discussed long time ago but never arrived to my current desktop could be discussed. If we want people to invent the future, they should at least know the past and gets also ideas from others. >> For example I would like to see the cost of it at the level of the GC. >> > > The main problem here, as also mentioned in discussion, is how GC > should deal with far references, i.e. > how to determine correctly when object which is referenced by some far > ref become garbage. May be a lifecycle like in Corba solution is needed at the level of each vat. > As for the rest of it, its not any different from usual approach: GC > could sweep a single vat space at any moment it wants, > regardless of what other vats currently doing. Stef

Feb. 3, 2010

Re: [Pharo-project] Fwd: Communicating Event Loops

by Igor Stasenko

On 3 February 2010 14:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > > You know Concurrent Smalltalk was certainly like that too. > Now my point is that this is good to share ideas that there are old or not. > Already discussed or not. Yes, that's why i asked , because i didn't understood your message. > For example I would like to see the cost of it at the level of the GC. > The main problem here, as also mentioned in discussion, is how GC should deal with far references, i.e. how to determine correctly when object which is referenced by some far ref become garbage. As for the rest of it, its not any different from usual approach: GC could sweep a single vat space at any moment it wants, regardless of what other vats currently doing. > Stef > >>> Begin forwarded message: >>> >>>> From: Tom Van Cutsem <tvcutsem(a)vub.ac.be> >>>> Date: February 3, 2010 5:13:00 AM GMT+01:00 >>>> To: SOFT members <soft(a)soft.vub.ac.be> >>>> Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Subject: Communicating Event Loops >>>> >>>> Hi, >>>> >>>> For those interested in concurrency control: last week I gave a presentation about AmbientTalk's concurrency model at a meeting for Javascript industry developers. The presentation was recorded, and if you're interested you can see it here: >>>> http://ssjs.pbworks.com/Communicating-Event-Loops >>>> >>>> (towards the end there is an interesting discussion about the pros and cons of Erlang-style vs AmbientTalk-style concurrency) >>>> >>>> Cheers, >>>> Tom >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 3, 2010