March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] adding messages dinamically to a single instance object

by HernÃ¡n Morales Durand

Hola Pablo, This technique is not something new, it was reported at least +20 years ago. You can read about it in a SO answer I wrote; http://stackoverflow.com/a/14202534 where there is a link to a foundational paper. Let us know what are you trying to do. Cheers, HernÃ¡n 2017-03-03 10:07 GMT-03:00 Pablo R. Digonzelli <pdigonzelli(a)gmail.com>: > Hi all. I need to know how can i do if i want add new behaviour ( a new > method ) to a single instance object of a class. > It means not to add new selector to the class but i want a single instance > responds that mesage. > Where can i read about it? > Tia > > ------------------------------ > *Ing. Pablo Digonzelli* > Software Solutions > IP-Solutiones SRL > Dividato SA > 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 >

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Sven Van Caekenberghe

> On 6 Mar 2017, at 14:12, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Here is a concrete proposal: > > https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-resu… > > This gives the following assertions: > > "Concatenating 2 symbols results in abother symbol" > self assert: (#foo , #bar) == #foobar. > > "Concatenating the empty symbol does not change a symbol" > self assert: (#foo, emptySymbol) == #foo. > self assert: (emptySymbol, #foo) == #foo. > > "Strings and symbols can still be mixed, the receiver determines the result type" > "Symbol receiver gives symbol result" > self assert: (#foo , 'bar') == #foobar. > "String receiver gives string result" > self deny: ('foo' , #bar) == #foobar. > self assert: ('foo' , #bar) equals: #foobar. > self assert: ('foo' , #bar) equals: 'foobar'. > > > Those last two seem contradictory. No, Symbols and String can be used interchangeably in Pharo in lots of contexts. Particularly when comparing them, it makes no difference, all the following are/have always been true, independent of this change: #foo = 'foo' 'foo' = #foo #foo = #foo 'foo' = 'foo' But maybe it is a bit confusing with an extra comment. > cheers -ben > > > > On 5 Mar 2017, at 19:53, Martin McClure <martin(a)hand2mouse.com> wrote: > > > > On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote: > >> I also think that allowing concatenation on Symbols does not violate their immutability contract. > >> > >> As a thought experiment, what could be the problem with adding > >> > >> Symbol >> , arg > >> ^ (self , arg) asSymbol > >> > >> ? > >> > > > > Aside from the infinite recursion (I suspect you meant super rather than self) :-) , I wouldn't have any problem with that. > > > >> > >> (I have found the original issue raised annoying as well) > >> > >> > >>> On 5 Mar 2017, at 11:35, Peter Uhnak <i.uhnak(a)gmail.com> > >>> wrote: > >>> > >>> I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. > >>> $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... > >>> > > Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not seen this feature used often, except by internal operations that could just as well be using a CharacterBuffer or whatever would replace String as the mutable thing if you made String immutable. > > > > Regards, > > > > -Martin

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Ben Coman

On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Here is a concrete proposal: > > https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol- > concatenation-results-in-a-Symbol-not-a-String > > This gives the following assertions: > > "Concatenating 2 symbols results in abother symbol" > self assert: (#foo , #bar) == #foobar. > > "Concatenating the empty symbol does not change a symbol" > self assert: (#foo, emptySymbol) == #foo. > self assert: (emptySymbol, #foo) == #foo. > > "Strings and symbols can still be mixed, the receiver determines > the result type" > "Symbol receiver gives symbol result" > self assert: (#foo , 'bar') == #foobar. > "String receiver gives string result" > self deny: ('foo' , #bar) == #foobar. > self assert: ('foo' , #bar) equals: #foobar. > self assert: ('foo' , #bar) equals: 'foobar'. > Those last two seem contradictory. cheers -ben > > > On 5 Mar 2017, at 19:53, Martin McClure <martin(a)hand2mouse.com> wrote: > > > > On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote: > >> I also think that allowing concatenation on Symbols does not violate > their immutability contract. > >> > >> As a thought experiment, what could be the problem with adding > >> > >> Symbol >> , arg > >> ^ (self , arg) asSymbol > >> > >> ? > >> > > > > Aside from the infinite recursion (I suspect you meant super rather than > self) :-) , I wouldn't have any problem with that. > > > >> > >> (I have found the original issue raised annoying as well) > >> > >> > >>> On 5 Mar 2017, at 11:35, Peter Uhnak <i.uhnak(a)gmail.com> > >>> wrote: > >>> > >>> I don't need (or want) to mutate the receiver. Actually I thought that > String is also immutable. > >>> $, could just return a new symbol instance instead. Concating symbols > is quite practical for metaprogramming, as most things are named with > symbols and compare by identity... > >>> > > Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not > seen this feature used often, except by internal operations that could just > as well be using a CharacterBuffer or whatever would replace String as the > mutable thing if you made String immutable. > > > > Regards, > > > > -Martin > > >

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Peter Uhnak

Thanks Sven! this looks good, and now also behaves same way as concating other collections (that is, the result type is the receivers' type). Peter On Mon, Mar 06, 2017 at 10:54:32AM +0100, Sven Van Caekenberghe wrote: > Here is a concrete proposal: > > https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-resu… > > This gives the following assertions: > > "Concatenating 2 symbols results in abother symbol" > self assert: (#foo , #bar) == #foobar. > > "Concatenating the empty symbol does not change a symbol" > self assert: (#foo, emptySymbol) == #foo. > self assert: (emptySymbol, #foo) == #foo. > > "Strings and symbols can still be mixed, the receiver determines the result type" > "Symbol receiver gives symbol result" > self assert: (#foo , 'bar') == #foobar. > "String receiver gives string result" > self deny: ('foo' , #bar) == #foobar. > self assert: ('foo' , #bar) equals: #foobar. > self assert: ('foo' , #bar) equals: 'foobar'. > > > On 5 Mar 2017, at 19:53, Martin McClure <martin(a)hand2mouse.com> wrote: > > > > On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote: > >> I also think that allowing concatenation on Symbols does not violate their immutability contract. > >> > >> As a thought experiment, what could be the problem with adding > >> > >> Symbol >> , arg > >> ^ (self , arg) asSymbol > >> > >> ? > >> > > > > Aside from the infinite recursion (I suspect you meant super rather than self) :-) , I wouldn't have any problem with that. > > > >> > >> (I have found the original issue raised annoying as well) > >> > >> > >>> On 5 Mar 2017, at 11:35, Peter Uhnak <i.uhnak(a)gmail.com> > >>> wrote: > >>> > >>> I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. > >>> $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... > >>> > > Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not seen this feature used often, except by internal operations that could just as well be using a CharacterBuffer or whatever would replace String as the mutable thing if you made String immutable. > > > > Regards, > > > > -Martin > >

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Sven Van Caekenberghe

Here is a concrete proposal: https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-resu… This gives the following assertions: "Concatenating 2 symbols results in abother symbol" self assert: (#foo , #bar) == #foobar. "Concatenating the empty symbol does not change a symbol" self assert: (#foo, emptySymbol) == #foo. self assert: (emptySymbol, #foo) == #foo. "Strings and symbols can still be mixed, the receiver determines the result type" "Symbol receiver gives symbol result" self assert: (#foo , 'bar') == #foobar. "String receiver gives string result" self deny: ('foo' , #bar) == #foobar. self assert: ('foo' , #bar) equals: #foobar. self assert: ('foo' , #bar) equals: 'foobar'. > On 5 Mar 2017, at 19:53, Martin McClure <martin(a)hand2mouse.com> wrote: > > On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote: >> I also think that allowing concatenation on Symbols does not violate their immutability contract. >> >> As a thought experiment, what could be the problem with adding >> >> Symbol >> , arg >> ^ (self , arg) asSymbol >> >> ? >> > > Aside from the infinite recursion (I suspect you meant super rather than self) :-) , I wouldn't have any problem with that. > >> >> (I have found the original issue raised annoying as well) >> >> >>> On 5 Mar 2017, at 11:35, Peter Uhnak <i.uhnak(a)gmail.com> >>> wrote: >>> >>> I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. >>> $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... >>> > Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not seen this feature used often, except by internal operations that could just as well be using a CharacterBuffer or whatever would replace String as the mutable thing if you made String immutable. > > Regards, > > -Martin

March 6, 2017

Re: [Pharo-users] adding messages dinamically to a single instance object

by Pablo R. Digonzelli

Hi Stef. I was reading your link. I found it very interesting . I think i will working in that direction having in mind your advise. Tia Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "stepharong" <stepharong(a)free.fr> Para: "Steven Costiou" <steven.costiou(a)kloum.io>, "Pablo Digonzelli" <pdigonzelli(a)gmail.com>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: SÃ¡bado, 4 de Marzo 2017 6:18:24 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object It is really possible and we are working on a new implementation of talents based on anonymous classes. Now what you should know is that - i would use this mechanism for debugging/tooling - i would try to avoid this as much as possible for domain modeling because it breaks all the hidden assumptions we have. stef Hi Steven . For the moment i just want to understand how it is possible. In the future may be i can apply this mechanism for future projects. Pablo Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Steven Costiou" <steven.costiou(a)kloum.io> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> CC: "Pablo Digonzelli" <pdigonzelli(a)gmail.com> Enviados: Viernes, 3 de Marzo 2017 11:03:23 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object Hi, could you describe why you need this ? Do you have a usecase ? Just interested to know, as i work on similar mechanisms. Steven. Le 2017-03-03 14:55, Pablo R. Digonzelli a Ã©crit : BQ_BEGIN Thanks Denis, I will take a look . I think this is what i need. Tia Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Denis Kudriashov" <dionisiydk(a)gmail.com> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: Viernes, 3 de Marzo 2017 10:11:53 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object Hi. Look at project Talents https://github.com/tesonep/pharo-talents . Idea is to implement behaviour (also with state) in normal way with classes and then dynamically install it to any existing objects 2017-03-03 14:07 GMT+01:00 Pablo R. Digonzelli < pdigonzelli(a)gmail.com > : BQ_BEGIN Hi all. I need to know how can i do if i want add new behaviour ( a new method ) to a single instance object of a class. It means not to add new selector to the class but i want a single instance responds that mesage. Where can i read about it? Tia Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 BQ_END -- kloum.io BQ_END -- Using Opera's mail client: http://www.opera.com/mail/

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Sven Van Caekenberghe

> On 5 Mar 2017, at 19:53, Martin McClure <martin(a)hand2mouse.com> wrote: > > On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote: >> I also think that allowing concatenation on Symbols does not violate their immutability contract. >> >> As a thought experiment, what could be the problem with adding >> >> Symbol >> , arg >> ^ (self , arg) asSymbol >> >> ? >> > > Aside from the infinite recursion (I suspect you meant super rather than self) :-) , I wouldn't have any problem with that. Haha, I copied it from lower in the thread, but shame on me that I didn't see that right away ! >> (I have found the original issue raised annoying as well) >> >> >>> On 5 Mar 2017, at 11:35, Peter Uhnak <i.uhnak(a)gmail.com> >>> wrote: >>> >>> I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. >>> $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... >>> > Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not seen this feature used often, except by internal operations that could just as well be using a CharacterBuffer or whatever would replace String as the mutable thing if you made String immutable. Yes, this distinction, with a default for immutable ones, would be good. We got #beReadOnlyObject in Pharo, so I guess we can start experimenting. Especially literal strings should be read only. > Regards, > > -Martin

March 5, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Martin McClure

On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote: > I also think that allowing concatenation on Symbols does not violate their immutability contract. > > As a thought experiment, what could be the problem with adding > > Symbol >> , arg > ^ (self , arg) asSymbol > > ? Aside from the infinite recursion (I suspect you meant super rather than self) :-) , I wouldn't have any problem with that. > > (I have found the original issue raised annoying as well) > >> On 5 Mar 2017, at 11:35, Peter Uhnak<i.uhnak(a)gmail.com> wrote: >> >> I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. >> $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not seen this feature used often, except by internal operations that could just as well be using a CharacterBuffer or whatever would replace String as the mutable thing if you made String immutable. Regards, -Martin

March 5, 2017

Re: [Pharo-users] Crash in Athens

by Igor Stasenko

On 5 March 2017 at 11:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 5 Mar 2017, at 05:00, Alexander Samoylovich <samoylovich(a)gmail.com> > wrote: > > Hi Ronie, Esteban. > > Ronie's suggestion in the form Esteban presented it helped. > After implementing the fix I failed to crash my application any more. > > Will anybody be so kind to explain me what actually happens and why the > fix works? > It looks so innocent. > > > Cairo Surface is GCd if not kept while using itâ¦ then your system go BOOM > :P > thatâs why we need to be sure it will not be disposed before itâs time > (hence we kept it in the form that needs to be displayed). > > Well, this surely helps when you changing session(s). But doesn't helps when you crashing within a single session. A smarter approach will be to recreate surface at attempt to use in new session, to avoid keeping copy of data around.. > Esteban > > -- Best regards, Igor Stasenko.

March 5, 2017

Re: [Pharo-users] Voyage and duplicated entry

by Hilaire

Understood. My use/understanding of hash and =, true in DrGeo, was more like unique identifier regarding its ontological characteristics (what distinguish it from other). So an exact same Point in DrGeo will have different hash value depending on its position on the plane, or it being free on a line, etc. May be I got it biased here. Anyway problem solved, comparing protocol was just rampant code. Le 05/03/2017 Ã 12:52, Joachim Tuchel a Ã©crit : > Sounds like this has nothing to do with voyage. If you modify part of on object's unique identifier, it's another object. The best you can do is to use a synthetic id that has no business meaning and use that for object identity. -- Dr. Geo http://drgeo.eu

March 5, 2017