- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

> As Mariano writes, most applications implement a message #isAbstract > themselves with the exact semantics they require. I don't think a > generic message in Behavior is really useful, especially if it is not > used by the core system. In that case, we could have isAbstractClass or something else. I feel this information is important. > If the class > contains any method that sends #subclassResponsibility, the we > consider the class as abstract. I am not sure what "contains" means in that context. But apparently, the definition you gave is not sufficient. The presence of subclassResponsibility need to be checked in the methods obtained from superclasses. (the code I gave in my previous email does not satisfy this although). I will create an issue. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Mariano Martinez Peck

On Tue, Oct 27, 2009 at 1:04 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi, > > I've more closely looked at the failing tests and undeclared > references in the Pharo image. The test result is 14 expected > failures, 34 failures, 54 errors, 2 unexpected passes. Considering > that the Pharo-core ships with all tests green, this situation needs > to be fixed. > > First of all, I really want to thank you Adrian. I am always complaining about this, but I never took the time to do something. So I _really_ appreciate your work and I think this is very important for Pharo. I urge the package maintainers to closely look at the list below and > provide fixes and cleanups of their code. > > If there are packages without maintainers, may be this could be a task for Smalltalks 2009 Pharo Sprint in November. > There are also 9 tests failing from Pharo-core. I will take care of > those. > > Nil > ----- > - Sends deprecated message: #findLastOccuranceOfString:startingAt: > - A test opens a workspace that says: "Squeak is a beautiful language. > Look at http:\\www.squeak.org ..." > - Another test opens another workspace > - NSBuffer has method that references an undeclared variable > 'collection' > - undeclared reference to GradientFillMorph, StringSocketStream > - Total failing tests: 10 > - Total tests with errors: 11 > > ECompleteion > ------------ > - 7 tests failing > - 2 errors > > O2 > -- > - #dropOnClass: references InputSensor (this class does not exist > anymore!) > - 15 undeclared references to OB* classes, to non-existent variable > hasChanges, modifiedTimeStamp, smartGroup, and sensor > - 11 failing tests > - >30 tests with errors > > OB > ------ > - undeclared references: HttpResponse, Json, JsonObject > - #dropOnClass: references InputSensor (this class does not exist > anymore!) > > NewInspector > ------------ > - undeclared reference automaticallyHideIfNoChild > - NewInspector DNU #inspect (sent in #testSymbolTableM6812) > > Shout > ----- > - undeclared variable sourceMap > > RB > -- > - undeclared reference to RBBasicLintRuleTest and > RBTransformationRuleTest > > Pharo-core tests failing > ------------------------ > - FontTest>>testFallback (assumes different font, to be removed) > - FontTest>>testParagraphFallback (assumes different font, to be > removed) > - FontTest>>testResetAfterEmphasized (assumes different font, to be > removed) > - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different > font, to be removed) > - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes > different font, to be removed) > - TestIndenting>>testSetUp (assumes different font, to be removed) > - LocaleTest>>testIsFontAvailable (some Japanese font checking that > fails with DejaVu, to be removed) > - testFinalizationOfEquals (was on my to do list, but works again: > remove expected failure tag) > - testObsoleteClasses: again includes classes from MC and others (have > to be checked) > > MorphExamplesAndDemos > --------------------- > - undeclared references to DescriptionForPartsBin and ScreeningMorph > > Cheers, > Adrian > > BTW, Damien, do we know for each package who the maintainer is? Does > each package have one? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Lukas Renggli

> The only problem I see (maybe I am wrong) here is that there are already a > lot of implementors of isAbstract. For example, those used in Sunit. So, if > you add this method to Behavior, there will be a lot of non-intentional > overrides. As Mariano writes, most applications implement a message #isAbstract themselves with the exact semantics they require. I don't think a generic message in Behavior is really useful, especially if it is not used by the core system. Interesting in this context is how the Refactoring Engine determines if a class is abstract: "Smalltalk doesn't have any language feature that denotes an abstract class like C++ or Java. As a result, we check for a couple things when looking for an abstract class. If the class contains any method that sends #subclassResponsibility, the we consider the class as abstract. A method that sends subclassResponsibility signifies that users should override this method in every subclass to have all the class' functionality to work. Another check we use to determine if a class is abstract is to look for references to the class. If the class is not referenced then the class is considered to be abstract, since there is no way to create an instance of the class." [http://st-www.cs.illinois.edu/users/brant/Refactory/] Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

> The only problem I see (maybe I am wrong) here is that there are > already a lot of implementors of isAbstract. For example, those used > in Sunit. So, if you add this method to Behavior, there will be a > lot of non-intentional overrides. I thought about it, but I haven't felt this could be a real problem. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Mariano Martinez Peck

On Wed, Oct 28, 2009 at 10:22 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Dear List, > > I was looking for a way to test whether a class is abstract or not. > One easy way, is to check whether the class sends the message > subclassResponsibility. This is not perfect, since we should also > check whether the receiver is 'self' and this is the only statement in > the method body. Looking at sender of #subclassResponsibiliy did not > reveal anything. I propose to define the following method: > > Behavior>>isAbstract > ^ self methods anySatisfy: [:cm | cm sendsSelector: > #subclassResponsibility ] > > The only problem I see (maybe I am wrong) here is that there are already a lot of implementors of isAbstract. For example, those used in Sunit. So, if you add this method to Behavior, there will be a lot of non-intentional overrides. > Shall I can create an issue and add a changeset? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2009

[Pharo-project] Abstract classes

by Alexandre Bergel

Dear List, I was looking for a way to test whether a class is abstract or not. One easy way, is to check whether the class sends the message subclassResponsibility. This is not perfect, since we should also check whether the receiver is 'self' and this is the only statement in the method body. Looking at sender of #subclassResponsibiliy did not reveal anything. I propose to define the following method: Behavior>>isAbstract ^ self methods anySatisfy: [:cm | cm sendsSelector: #subclassResponsibility ] Shall I can create an issue and add a changeset? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] How to make Pharo produce random garbage bytes

by Lukas Renggli

If you are up to that kind of random data you can also try Object new executeMethod: (Point >> #x) Lukas 2009/10/28 Niko Schwarz <niko.schwarz(a)googlemail.com>: > Hi list, I learned something fun today from a friend, how to make > Pharo produce random garbage! > > Â Make a class AC which is defined as: > Â Object subclass: #AC > Â Â Â instanceVariableNames: 'a' > Â Â Â classVariableNames: '' > Â Â Â poolDictionaries: '' > Â Â Â category: 'OB-Standard-Browsers' > > Then you make a second class AB defined as: > > Object variableByteSubclass: #AB > Â Â Â instanceVariableNames: '' > Â Â Â classVariableNames: '' > Â Â Â poolDictionaries: '' > Â Â Â category: 'OB-Standard-Browsers' > > Then you make accessors for 'a' in AC > Now execute: AB superclass: AC > And then you do "AB new a" which gives you back random data. > > > Cheers, > > Niko > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 28, 2009

[Pharo-project] How to make Pharo produce random garbage bytes

by Niko Schwarz

Hi list, I learned something fun today from a friend, how to make Pharo produce random garbage! Make a class AC which is defined as: Object subclass: #AC instanceVariableNames: 'a' classVariableNames: '' poolDictionaries: '' category: 'OB-Standard-Browsers' Then you make a second class AB defined as: Object variableByteSubclass: #AB instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'OB-Standard-Browsers' Then you make accessors for 'a' in AC Now execute: AB superclass: AC And then you do "AB new a" which gives you back random data. Cheers, Niko

Oct. 28, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Alain Plantec

Igor Stasenko wrote: > 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > well, my initial idea is to enable a package developer to establish own policy > for his package. > A policy get notified of any change before it made and of course > doesn't cares if there's anyone > who listens for notifications of changes, after they applied. > The open question, is how to allow developer to not only use > predefined set of flags for policy, > but also introduce own custom rules. For example, one might want check > the submitted method against lint rules, > and prevent method from being installed if rules not satisfied :) > > You defined a set of announcement classes, each one is for a particular kind of event. So, no need for #changeKind and #parameters dictionary instance variable (please no!). The action which is applied is simply implemented by the announce sender. Before a system event occurs, an announce is sent saying that the event is about to occur. Then declared listeners could decide if the event can really occur (if a listener is in a state which forbid the event then it can change the announce which was sent). If the sent announce is not change (recall that this is an object), then it means that a consensus about the feasibility of the event is obtained. Then the particular event can occur. After, an announce indicating that the event has occurred is sent. I'm not sure but I think that seaside is already using announcements with such kind of consensus protocol. Alain

Oct. 28, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Igor Stasenko

2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Any change to system should be captured _before_ it applied. >> This allows us to introduce a policy which can validate the change >> and decide >> whether it allowed to be made or not. >> >> I made the SystemChangeEvent class, which having following state: >> - changeKind - a symbol, which identifies the change >> - parameters - a dictionary , which holding different parameters, >> important for change >> - subject - the object which is going to be changed (or taking a main >> role in change) >> - action - a block closure which , if evaluated, will apply the >> change to system > > why not using announcement? sure, why not :) > >> For example, here the method which creates & populates the system >> change event: >> >> classify: element under: heading suppressIfDefault: aBoolean >> >> Â Â Â (self subject newSystemEvent: #changeSelectorCategory) >> Â Â Â Â Â Â Â subject: element; >> Â Â Â Â Â Â Â param: #behavior->self subject; >> Â Â Â Â Â Â Â param: #category->heading asSymbol; >> Â Â Â Â Â Â Â param: #suppressIfDefault->aBoolean; >> Â Â Â Â Â Â Â action: [ super classify: element under: heading suppressIfDefault: >> aBoolean ]; >> Â Â Â Â Â Â Â signal. >> --------- >> >> The event handling procedure is following: >> >> - first of all, an event passed to a system arbiter object >> - a system arbiter checking with the policy >> - if everything ok, change is applied by evaluating action. >> - and finally, change is announced to any interesting parties >> >> I want to make each package to hold own policy (a set of flags >> identified by name, to ease fileout). > > Why only easing fileout it seems to me that this is not related to > notification of changes? > well, my initial idea is to enable a package developer to establish own policy for his package. A policy get notified of any change before it made and of course doesn't cares if there's anyone who listens for notifications of changes, after they applied. The open question, is how to allow developer to not only use predefined set of flags for policy, but also introduce own custom rules. For example, one might want check the submitted method against lint rules, and prevent method from being installed if rules not satisfied :) >> Then, any event could be validated by policy by issuing: >> package policy validate: change >> >> For example, lets see , what validations we could introduce for method >> recategorization event. >> >> Â - lets take most interesting case, when we want to recategorize the >> method in ClassA, which belongs to PackageA, >> Â and putting it into extension category, like *PackageB >> >> Â - check, if we allow any changes to ClassA (policy of PackageA) >> Â - check if PackageA allows method extensions (policy of PackageA) >> Â - check if PackageB allows extending the classes of another packages >> (policy of PackageB) >> Â - check if extension overrides existing method >> Â - and of course, we should check that given extension does not >> creates a circular dependency between the packages. > > I would like to understand why do we want package to get a policy? > Simple. a) In case of any changes, the class environment should be notified, NOT some global. b) in a future, i want to change the class environment to be a package, to which it belongs to. Hence, the package could have own, unique policy, or refer to system-wide one. But it is package, who receiving notifications first, and should be first who in control how to handle them. >> There, of course, some problems which arising. >> - changes nesting. >> Â Some changes is complex ones, and even a simple method >> recategorization could lead to another event - creating a new >> Â category in class. Â Optimally, it would be cool to have only most >> basic events, which can't be nested. And any action which may lead to >> multiple changes, should be split on a number of basic ones. >> A SystemChangeNotifier solving this by allowing doing things silently: >> Â SystemChangeNotifier uniqueInstance doSilently: [ ... ]. >> so, any changes within the block , if any, won't be announced. >> >> - atomicity support. To support the bulk model updating, i can imagine >> the framework, which capturing any changes without applying them, by >> building/collecting all changes in parallel, and then applying them by >> a single mass-become. This is what SystemEditor does. >> >> - metaprogramming. There should be a means to leave a room for >> metaprogramming. We wouldn't want to signal a system change for >> anonymous classes, and many other things, which can be tricky here. >> >> P.S. as you can see , the plans is quite bold, and will require >> numerous refactorings :) So, the more people is interested in that, >> the better. > > > My gut feeling is to say: > Â Â Â Â - let us study what is there > Â Â Â Â - can we migrate to announcement Yes, we can (c) Its good that you remind me about announcements framework. And you are right, that implementing this using announcements is good idea. But i feel a bit uncomfortable facing the need to spawn a lot of (sub)classes for that purpose. Obviously, the kernel should handle all of system events without exceptions, hence a kernel doesn't really needs to know such finely defined subclasses. While other subscribers may want to selectively listen for different things, which happening in a system. So, i want to hear what you and others think about it. > Â Â Â Â - slowly move from there. > > Stef > > _______________________________________________ > 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.

Oct. 28, 2009