May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] RPackage and overrides

by Marcus Denker

On May 30, 2013, at 2:22 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 30/05/2013 14:09, StÃ©phane Ducasse a Ã©crit : >> >> On May 30, 2 >>> Yes. I can say true become: false, too. >>> >>> Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes >>> the image package dirty. So later, when I know what I want, I will move that change to the image. >>> >>> You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. >>> Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things. >>> >>> So this is more something we should add a rule for in Code Crititqueâ¦ >> >> I'm not sure. Because something you really need them. > > I'd be worried then. > > Either we have a need for extension where only an override will do... Then why not modeling it and critique it when appropriate? Hiding it under an extension won't make the problem disappear, it will just hide it. > > But it just does not work: two overrides. Which will be called? Overrides are like halt: you use is while developing and for hacks, but shipped packages just can not use it, because there is just no semantic of multiple overrides. The only solution is to have system where extensions are private to you, but than the normal use case for overrides is to "hook into something". Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦ But as I said: my brain is full. I just can't think about it now. Marcus

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by Goubier Thierry

Le 30/05/2013 14:09, StÃ©phane Ducasse a Ã©crit : > > On May 30, 2 >> Yes. I can say true become: false, too. >> >> Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes >> the image package dirty. So later, when I know what I want, I will move that change to the image. >> >> You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. >> Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things. >> >> So this is more something we should add a rule for in Code Crititqueâ¦ > > I'm not sure. Because something you really need them. I'd be worried then. Either we have a need for extension where only an override will do... Then why not modeling it and critique it when appropriate? Hiding it under an extension won't make the problem disappear, it will just hide it. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by StÃ©phane Ducasse

On May 30, 2 > Yes. I can say true become: false, too. > > Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes > the image package dirty. So later, when I know what I want, I will move that change to the image. > > You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. > Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things. > > So this is more something we should add a rule for in Code Crititqueâ¦ I'm not sure. Because something you really need them. Stef

May 30, 2013

Re: [Pharo-dev] Trait exclusions

by StÃ©phane Ducasse

On May 30, 2013, at 11:03 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Hi Stef, > > Indeed you'd normally not double apply a trait. I want to do that here > for explanatory purposes, to show that a field is the melding of two > groups. > > As it turns out, this double application merely highlights my > underlying issues. My problems would still be there whenever I wanted > to compose traits that shared requirements. oki > I had understood the "symmetric composition annihilates conflicting > methods" in "Traits: composable units of behaviour" to mean that the > composition would not have such methods _at all_. No. This sentence is strange. But > In Pharo, if you > have two traits S and T, and a common method m, the composition S + T > does contain m. If S and T implement m differently, the resulting m is > "self traitConflict". If both S and T implement m as "self > requirement", the resulting composition's m is also "self > requirement". for requirement this is special and not well implemented in Pharo. if you have a method T1>>m ^ 42 T2>>m ^ 66 T = T1 + T2 => you have to redefine m in T T = T1-m + T2 => you get m -> 66 Now you can also alias it: ie you give a new name to the method m You can read freezable traits because there is a nice explanation. > That surprised me, but it does actually make sense. It > does mean that (S + T) != (S - m) + (T - m). I do not know :) what I know is that (S + T) can have a conflict ion m while (S - m) + (T - m) ensure you do not have a conflict > What I'd also expected is that aliasing (say, S @ {#m -> #z}) would > mean "the resulting composition does not understand m". But it does. No this is just aliasing not renaming because we cannot resolve statically renaming in dynamic language. > > So in my case, I had expected that TGroup @ {#identity->#zero. #* -> > #+. #inverse->#negated} would result in a Trait that didn't define > #identity or #inverse, and that TGroup @ {#identity->#one. > #inverse->#reciprocal} would likewise not define #identity or > #inverse. Yes I see what you mean. May be this is an implementation problem. Because we could remove the origin of the bound methods > Then resulting composition would have no conflicts, and > would simply understand #(#* #+ #negated #reciprocal #one #zero). Yes this is probably a bug of the implemantation. I do not remember what we wrote in the papers > > frank > > On 30 May 2013, at 7:51, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> Hi frank >> >> normally it does not make sense to use two times the same trait. So I do not really understand >> how it could work. >> >> So now when you have two traits >> T1 >> T2 >> >> minus lets you erase selectively one message x from T1 if it is also available in T2 >> and without having to redefine it into the composite. >> >> Stef >> >>> I have a Trait TGroup that requires #*, #identity and #inverse. I want >>> to construct a TField by composing TGroup with itself. One TGroup will >>> form the operations #*, #one, and #reciprocal while the other will >>> form #+, #zero and #negated. >>> >>> I don't want #identity or #inverse, because these apply to one >>> operation, and it makes TField's API ambiguous. That's what >>> TraitExclusion is for. >>> >>> I had thought I could say >>> >>> (TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} + TGroup @ >>> {#identity->#one. #inverse->#reciprocal}) - {#identity. #inverse} >>> >>> but TraitComposition >> #- says that exclusion binds tighter than +. >>> So in effect the above composition is the same as >>> >>> TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} + (TGroup @ >>> {#identity->#one. #inverse->#reciprocal} - {#identity. #inverse}) >>> >>> In short, to remove the undesirable #identity and #inverse I have to >>> exclude from both sides of the composition: >>> >>> TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} - >>> {#identity. #inverse} + TGroup @ {#identity->#one. >>> #inverse->#reciprocal} - {#identity. #inverse} >>> >>> My question is this: what is the reason for - binding more tightly >>> than +? Why is it _not_ desirable to have - distribute over +? >> >

May 30, 2013

Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)

by StÃ©phane Ducasse

On May 30, 2013, at 12:36 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stephane ducasse wrote >> I started to read the chapter to understand. > > After talking with Andres, I found out he did an implementation in VW called > Assessments that went far beyond the book. One more reason to get > cross-platform filetree/cypress working ;) But I'm fascinated by the idea of > ongoingly monitoring the health of models. It would be great for > SimplePersistence and other serialization libraries to check the model after > materializing to make sure everything is as expected. The potential for > really non-intrusive UI validation is obvious, and exciting too! > > yes he presented it at amsterdam and it looks really interesting. > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690751.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 30, 2013

Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)

by Sven Van Caekenberghe

Cool stuff indeed. And yes, some months ago I read Andres Valloud's 'A Mentoring Course on Smalltalk', also because you wrote about it on your blog - it is indeed one of the best books about programming (and Smalltalk), although a bit advanced. On 30 May 2013, at 08:58, Max Leske <maxleske(a)gmail.com> wrote: > I love the music you used in your screencast :D Sounds a bit like a telephone waiting line I meant to write something funny about the music as well. I was expecting to hear a native English speaker, but no ! > On 30.05.2013, at 08:52, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> I started to read the chapter to understand. >> >> Stef >> >> >>> stephane ducasse wrote >>>> show us how you specify that? >>> >>> It's a simple Spec UI, receiving announcements from the domain object. >>> Whenever the model changes, the UI receives: >>> modelChanged: anAnnouncement >>> >>> failureList items: model validate failures. >>> >>> #validate is the main entry point for the framework. You can call this on >>> any domain object and the validation rules will be run. Under the hood are >>> specialized SUnit classes. Here (on Nabble) is a screenshot of the validator >>> class, a specialized TestCase which holds the rules for the object in the >>> screencast: >>> <http://forum.world.st/file/n4690694/Screen_Shot_2013-05-29_at_5.37.12_PM.png> >>> >>> The really cool thing which is not shown in the video is that the failures >>> are real objects which hold the domain object, the property that failed >>> (called an 'aspect'), and the description shown in the UI. So you could do a >>> lot more than show the description... >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690694.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >> > >

May 30, 2013

Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)

by Sean P. DeNigris

stephane ducasse wrote > I started to read the chapter to understand. After talking with Andres, I found out he did an implementation in VW called Assessments that went far beyond the book. One more reason to get cross-platform filetree/cypress working ;) But I'm fascinated by the idea of ongoingly monitoring the health of models. It would be great for SimplePersistence and other serialization libraries to check the model after materializing to make sure everything is as expected. The potential for really non-intrusive UI validation is obvious, and exciting too! ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690751.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 30, 2013

Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)

by Sean P. DeNigris

Max Leske wrote > I love the music you used in your screencast :D Sounds a bit like a > telephone waiting line Ha ha, it was just whatever random thing was on grooveshark while I was hacking :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690750.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 30, 2013

Re: [Pharo-dev] [update 3.0] #30174

by Marcus Denker

On May 30, 2013, at 10:47 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > 10759 AnObsoleteDefaultCommandLineHandler is in the image > https://pharo.fogbugz.com/f/cases/10759 This did not help, there is still: Obsolete classes remaining: an Array(AnObsoleteDefaultCommandLineHandler) I added a new tracker entry https://pharo.fogbugz.com/f/cases/10805 Marcus

May 30, 2013

Re: [Pharo-dev] #"asdada"B is a valid symbol?

by Frank Shearar

On 29 May 2013 21:09, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 May 2013 20:55, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 29 May 2013 19:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> I see no harm in that. >>> >>> It might be misleading, >> >> Well, that's _exactly_ the harm in that. >> > so don't write it like that :) Sure, but that's the inverse of the problem. The problem isn't that _you_ can write a comment anywhere. It's that when you're reviewing my code _I_ can put a comment anywhere, and make your day that little bit worse. One answer to that is a lint rule, I suppose, and then you reject my submission because I did some crazy nonsense with comments. > I actually like the fact that i can put comment anywhere i want, and > it doesn't disrupts the parser. > Of course, it turns to be a problem, when you think that something > must be represented by a single token > but it cannot, because it split by comment. Exactly, which makes parsing that little bit worse. > But to me it is much more important that i can put comment anywhere i > like, without thinking "oh.. it may not compile". I suppose that's fine for hacking around. I just wouldn't want to review code with these kinds of comments in it. QA's hard enough already. frank >> frank >> >>> but who in his/her sane mind would write like that? >> >>> Apparently the parser removes all the comments before doing anything else. >>> >>> Esteban A. Maringolo >>> >>> >>> 2013/5/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >>>> >>>> Ah, nice, we can write in french ;) 221" millions "355" mille "799 >>>> >>>> >>>> 2013/5/29 Gisela Decuzzi <giseladecuzzi(a)gmail.com> >>>>> >>>>> >>>>> 2013/5/29 Frank Shearar <frank.shearar(a)gmail.com> >>>>>> >>>>>> How does 1"sdads"2 evaluate? To 12? >>>>> >>>>> >>>>> Yes the same... 1"sdads"2 is interpreted as 12 and all estrange >>>>> combinations... >>>>> >>>>> I think this shouldn't be valid but since there are tests verifying the >>>>> behavior maybe there was a reason (more than the scanner we are using is >>>>> skipping all the comments without letting the parser decide) >>>>> >>>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

May 30, 2013