- Pharo-dev - lists.pharo.org

[Pharo-project] Problem installing Magritte2

by Casimiro de Almeida Barreto

The following: (Installer squeaksource project: 'MetacelloRepository'; packagesMatching: 'ConfigurationOfMagritte2-*') first install. ConfigurationOfMagritte2 project latestVersion load. Results in: Error: could not resolv Magritte-Model [Magritte-Model-lr.397] Then, the site: source.lukas-renggli.ch returns: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. ------------------------------------------------------------------------ Apache/2.2.14 (Ubuntu) Server at source.lukas-renggli.ch Port 80

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

Almost... :-) it would be: performedExperiment := PerformedExperiment for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" with: aCollectionOfTasks. DNU => HIT CREATE BUTTON => Automatically create the following methods 1) PerformedExperiment class >> for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. | instance | instance := self new. instance initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. ^ instance Save - Proceed - DNU -> Create Button -> 2) PerformedExperiment>> initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. self shouldBeImplemented. " Suggested code - Uncomment it if you like it :-) experiment := anExperiment. startTime := aStartTime. stopTime := aStopTime. participant := aParticipant. taks := aCollectionOfTasks. " The template can be created that way because it knows it is an initialize message, so it takes the parameter names to suggest the inst var names and assign to them the right parameters. Having these kind of "idioms" can really help when creating code automatically in such a context like the debugger 2010/10/14 Fernando olivero <fernando.olivero(a)usi.ch> > So a "smart template" created by the debugger would just do the following, > when defining the following Class method: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is > not a good name" > with: aCollectionOfTasks. > > DNU => HIT CREATE BUTTON => Automatically create the following methods > > 1) > PerformedExperiment class >> > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > | instance | > instance := self new. > instance > initializeFor: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > ^ instance > > 2) > PerformedExperiment>> initializeFor: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > self shouldBeImplemented > > > > > > On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > > Hi Fernando, > I think that you are saying that having too many parameter could be a > problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, > and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have > an instance creation message that creates a "complete" object, then you > would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would > use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone > (in the former you can forget to send a message, ie. stop: and nobody will > complain immediately, but in the last one you wont make that mistake, or if > you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it > could bother a little the reading, but when there are so many parameters I > format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the > inst. creation message. This helps when analyzing code automatically (ie. > initialize messages should only be sent from the class side) or generating > code automatically on the debugger with the create button (as the > enhancement 3099 that I sent the other day, the debugger could be smart > enough to realize it is an initialization message so it could provide a > better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using > as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is > not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like > "experimient: anExperiment", "start: anStartTime", etc., with the last one > you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch > > wrote: > >> Hi Hernan, just wanted to get your opinion on the following method, that >> attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). >> >> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks >> | experiment | >> experiment := self new. >> experiment experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks. >> ^ experiment >> >> >> In your experience, how does the pattern cope with large keyword >> selectors. >> >> Maybe this case is not that evident, although we should try to avoid >> having more than 4 instance variables anyway, i would like to get your >> opinion on this problem (?). >> >> Thanks, >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > <ATT00001..txt> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

cool! remember also the other tip, that the object should be valid from scratch... so, for this example I would do something like this: PerformedExperiment class>>for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks PatAssertionsRunner valueWith: (self assertionForPerformedExperimentStartedAt: aStartTime before: aStopTime). ^self new initializeExperimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks That way if the stoptime is before starttime (wich I beleive is an error in this case) the object is not created and you wont have an invalid performed experiment. You will see that asserting that something starts before the "stop" is very common, so I suggest to use an interval to represent that but not the smalltalk Interval that does not verify that condition but the Aconcagua Interval that verifies that intervals are valid. So you could change the message to something like this: PerformedExperiment class>>for: anExperiment during: aTimePeriod madeBy: aParticipant with: aCollectionOfTasks ^self new initializeExperimient: anExperiment during: aTimePeriod participant: aParticipant tasks: aCollectionOfTasks Doing so you get less parameters and only valid "time periods" (intervals) that leads to valid performed experiments. Another assertion that you may have is if aCollectionOfTasks can be empty... anyway, thinking about this constrains helps you to create a better model and understand the business rules. I hope it helps! Hernan. 2010/10/14 Fernando olivero <fernando.olivero(a)usi.ch> > THANKS Hernan! > > With the example i've got to understand the correct usage of the pattern > now. Which of course i will follow from now on, given the benefits from > having complete objects! ( no messy ifNil checks for starters!, etc...) > > > > > On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > > Hi Fernando, > I think that you are saying that having too many parameter could be a > problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, > and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have > an instance creation message that creates a "complete" object, then you > would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would > use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone > (in the former you can forget to send a message, ie. stop: and nobody will > complain immediately, but in the last one you wont make that mistake, or if > you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it > could bother a little the reading, but when there are so many parameters I > format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the > inst. creation message. This helps when analyzing code automatically (ie. > initialize messages should only be sent from the class side) or generating > code automatically on the debugger with the create button (as the > enhancement 3099 that I sent the other day, the debugger could be smart > enough to realize it is an initialization message so it could provide a > better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using > as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is > not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like > "experimient: anExperiment", "start: anStartTime", etc., with the last one > you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch > > wrote: > >> Hi Hernan, just wanted to get your opinion on the following method, that >> attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). >> >> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks >> | experiment | >> experiment := self new. >> experiment experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks. >> ^ experiment >> >> >> In your experience, how does the pattern cope with large keyword >> selectors. >> >> Maybe this case is not that evident, although we should try to avoid >> having more than 4 instance variables anyway, i would like to get your >> opinion on this problem (?). >> >> Thanks, >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > <ATT00001..txt> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Fernando olivero

So a "smart template" created by the debugger would just do the following, when defining the following Class method: performedExperiment := PerformedExperiment for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" with: aCollectionOfTasks. DNU => HIT CREATE BUTTON => Automatically create the following methods 1) PerformedExperiment class >> for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. | instance | instance := self new. instance initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. ^ instance 2) PerformedExperiment>> initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. self shouldBeImplemented On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > Hi Fernando, > I think that you are saying that having too many parameter could be a problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have an instance creation message that creates a "complete" object, then you would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone (in the former you can forget to send a message, ie. stop: and nobody will complain immediately, but in the last one you wont make that mistake, or if you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it could bother a little the reading, but when there are so many parameters I format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the inst. creation message. This helps when analyzing code automatically (ie. initialize messages should only be sent from the class side) or generating code automatically on the debugger with the create button (as the enhancement 3099 that I sent the other day, the debugger could be smart enough to realize it is an initialization message so it could provide a better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like "experimient: anExperiment", "start: anStartTime", etc., with the last one you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > Hi Hernan, just wanted to get your opinion on the following method, that attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). > > PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks > | experiment | > experiment := self new. > experiment experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks. > ^ experiment > > > In your experience, how does the pattern cope with large keyword selectors. > > Maybe this case is not that evident, although we should try to avoid having more than 4 instance variables anyway, i would like to get your opinion on this problem (?). > > Thanks, > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > <ATT00001..txt>

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Fernando olivero

THANKS Hernan! With the example i've got to understand the correct usage of the pattern now. Which of course i will follow from now on, given the benefits from having complete objects! ( no messy ifNil checks for starters!, etc...) On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > Hi Fernando, > I think that you are saying that having too many parameter could be a problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have an instance creation message that creates a "complete" object, then you would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone (in the former you can forget to send a message, ie. stop: and nobody will complain immediately, but in the last one you wont make that mistake, or if you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it could bother a little the reading, but when there are so many parameters I format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the inst. creation message. This helps when analyzing code automatically (ie. initialize messages should only be sent from the class side) or generating code automatically on the debugger with the create button (as the enhancement 3099 that I sent the other day, the debugger could be smart enough to realize it is an initialization message so it could provide a better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like "experimient: anExperiment", "start: anStartTime", etc., with the last one you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > Hi Hernan, just wanted to get your opinion on the following method, that attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). > > PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks > | experiment | > experiment := self new. > experiment experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks. > ^ experiment > > > In your experience, how does the pattern cope with large keyword selectors. > > Maybe this case is not that evident, although we should try to avoid having more than 4 instance variables anyway, i would like to get your opinion on this problem (?). > > Thanks, > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > <ATT00001..txt>

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Alexandre Bergel

> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks I guess you meant PerformedExperiment class >>experiment: ... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 14, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Schwab,Wilhelm K

That is wonderful news! Didier, There is a natural question that arises: what are the performance implications of Smalltalk or Java? Why not C with a Smalltalk wrapper? I have not tried number crunching with Cog or NativeBoost doing some of the expensive lifting, but absent those advantages, the benefit from coding tight loops in C has been nothing short of eerie. I have never tried Java for it. If there is a speed boost to be had, would a port offend you? I am a pragmatist, so it would begin one function at a time, chosen by the type of work I do and driven by when the machine grunts. Thanks, Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, October 14, 2010 4:02 PM To: Pharo Development; The general-purpose Squeak developers list; ESUG Mailing list Cc: Didier H. Besset Subject: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license I want to thanks didier for releasing the code of his book under MIT. Thanks! Begin forwarded message: > From: Didier Besset <didier(a)ieee.org> > Date: October 14, 2010 8:06:52 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Disclaimer > > I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license. > > Didier Besset _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

Hi Fernando, I think that you are saying that having too many parameter could be a problem for understanding the message, is that right? I mean, having too many inst var as you say, it is a smell of bad design, and having too many parameters also, so I guess we agree on that. About reading the code, from the sender point of view, if you don't have an instance creation message that creates a "complete" object, then you would do something like this: performedExperiment := PerformedExperiment new experimient: anExperiment; start: aStartTime ; stop: aStopTime ; participant: aParticipant; tasks: aCollectionOfTasks; yourself. With an inst. creation message that returns a complete object, you would use it like this: performedExperiment := PerformedExperiment experimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks. So, it is basically the same but with less messages and less error prone (in the former you can forget to send a message, ie. stop: and nobody will complain immediately, but in the last one you wont make that mistake, or if you doit you will get a dnu immediately). About the implementation of the inst. creation message, it is true that it could bother a little the reading, but when there are so many parameters I format the code this way: PerformedExperiment class>>experimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks ^self new initializeExperimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks that makes it more readable. Also look that there is an initializeXxx message to distinguish it from the inst. creation message. This helps when analyzing code automatically (ie. initialize messages should only be sent from the class side) or generating code automatically on the debugger with the create button (as the enhancement 3099 that I sent the other day, the debugger could be smart enough to realize it is an initialization message so it could provide a better template than just a "self shouldBeImplemented"). I the meantime, I would suggest another name for the message you are using as example, something easier to read like: performedExperiment := PerformedExperiment for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" with: aCollectionOfTasks. I think it reads better. With the former you have duplicated "names" like "experimient: anExperiment", "start: anStartTime", etc., with the last one you don't have that problem. Hope it helps, let me know what you think! Hernan. On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch>wrote: > Hi Hernan, just wanted to get your opinion on the following method, that > attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). > > PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime > participant: aParticipant tasks: aCollectionOfTasks > | experiment | > experiment := self new. > experiment experiment: anExperiment start: aTime stop: aStopTime > participant: aParticipant tasks: aCollectionOfTasks. > ^ experiment > > > In your experience, how does the pattern cope with large keyword selectors. > > Maybe this case is not that evident, although we should try to avoid having > more than 4 instance variables anyway, i would like to get your opinion on > this problem (?). > > Thanks, > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by StÃ©phane Ducasse

Thanks!!! Stef On Oct 14, 2010, at 8:32 PM, jaayer wrote: > The original contains an error; it send min: where it should max:. This one contains the correction.<Stack.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 14, 2010

Re: [Pharo-project] PharoKernel related issues

by StÃ©phane Ducasse

Thanks pavel!! I'm quite busy just right now but we will have a look. Stef On Oct 14, 2010, at 1:30 PM, Pavel Krivanek wrote: > Hi, > > if you want to have modular Pharo, you should pay attention to this > issues. Please look at them and write your oppinions on best solutions > of this PharoKernel related issues. > > Issue 3103: better Morphic detection in AutoStart startUp: > http://code.google.com/p/pharo/issues/detail?id=3103 > > Issue 3104: ChangeSet class >> #fileIntoNewChangeSet: dependent on Compression > http://code.google.com/p/pharo/issues/detail?id=3104 > > Issue 3105: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet > http://code.google.com/p/pharo/issues/detail?id=3105 > > Issue 3106: EToys resources relict in Form >> unhibernate > http://code.google.com/p/pharo/issues/detail?id=3106 > > Issue 3107: UserInterruptHandler >> handleEvent: is dependent on SoundService > http://code.google.com/p/pharo/issues/detail?id=3107 > > Issue 3108: Project >> updateLocaleDependents dependent on MenuIcons > http://code.google.com/p/pharo/issues/detail?id=3108 > > Issue 3109: TextURL >> #actOnClickFor: dependent on network > http://code.google.com/p/pharo/issues/detail?id=3109 > > Issue 3110: ProjectLauncher readDocumentAtStartup needs a setting > http://code.google.com/p/pharo/issues/detail?id=3110 > > Issue 3111: AutoStart class >> #checkForUpdates is Morphic dependent > http://code.google.com/p/pharo/issues/detail?id=3111 > > Issue 3112: ThreadSafeTranscript >> #endEntry is Morphic dependent > http://code.google.com/p/pharo/issues/detail?id=3112 > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 14, 2010