- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Deprecation policy

by csrabak＠bol.com.br

Aug. 31, 2011

Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalkand Pharo 1.4

by Dale Henrichs

Laszlo, Good ... I am planning a new release of Metacello in the near future (got to clear a couple of other things from my plate first) and it will include the pharo1.4.x attribute I will also run full test suite etc. on Pharo1.4 at that time ... Dale ----- Original Message ----- | From: "Laszlo Zsolt Kiss" <lzskiss(a)dublin.ie> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, August 30, 2011 3:27:59 PM | Subject: Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalkand Pharo 1.4 | | hi. | I tested this. | First load the: | | | 'Metacello-Base-DaleHenrichs.19' | 'Metacello-Core-DaleHenrichs.455' | 'Metacello-MC-DaleHenrichs.505' | | | then: | | | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfOpenDBXDriver'; | load. | | | then: | | | ((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) project | version: '1.0') load. | | | I gived just two warnings, after I proceed these warnings the DBXTalk | was loaded to the 1.4 #14112 image | Not the nice solution, but working with the 1.4. | I tested with the Firebird 2.5 on the Win32 platform. | | | Best regards. | | | Laszlo Zsolt | | | | ----- Original Message ----- | | | From: Pharo-project(a)lists.gforge.inria.fr | | To: <Pharo-project(a)lists.gforge.inria.fr> | | Cc: <dbxtalk(a)googlegroups.com> | | Sent: Tue, 30 Aug 2011 14:26:28 -0700 (PDT) | | Subject: Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: | DBXTalk and Pharo 1.4 | | | Mariano, | | I think that addVersion: is very old gofer/metacello code ... not | fancy new code. It sounds like an old version of Metacello is being | loaded/bootstrapped. #addVersion: isn't sent from the current code | base ... At a minimum, you should have these packages loaded: | | 'Metacello-Base-DaleHenrichs.19' | 'Metacello-Core-DaleHenrichs.455' | 'Metacello-MC-DaleHenrichs.505' | | if the bootstrapping process is working. | | Keep in mind that pharo1.4.x has not yet been defined in Metacello | (see Issue 4613[1]), so there will be other Metacello issues in 1.4 | for the moment ... the proposed bugfix in 4613 would mean that a new | version of Metacello would no longer be needed to define the | platform specific attributes ... | | Dale | | [1] http://code.google.com/p/pharo/issues/detail?id=4613 | | ----- Original Message ----- | | From: "Mariano Martinez Peck" < marianopeck(a)gmail.com > | | To: dbxtalk(a)googlegroups.com , "Pharo Development" < | | pharo-project(a)lists.gforge.inria.fr > | | Sent: Tuesday, August 30, 2011 2:00:26 PM | | Subject: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: | | DBXTalk and Pharo 1.4 | | | | | | | | | | On Tue, Aug 30, 2011 at 9:14 PM, Laszlo Zsolt Kiss < | | lzskiss(a)gmail.com > wrote: | | | | | | | | | | hi. | | first i load the ConfigurationOfOpenDBX and the 1.4 version is | | missing from the spec.: | | | | | | | | stable: spec | | <symbolicVersion: #stable> | | | | spec for: #'pharo1.2.x' version: '1.0'. | | spec for: #'pharo1.3.x' version: '1.0'. | | | | | | then i added the next line to the spec: | | | | | | spec for: #'pharo1.4.x' version: '1.0'. | | | | | | then i probally do it this: | | | | | | (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: | | #project) perform: #version: with: #stable) load. | | | | | | i gived back a warring: | | | | | | | | "The method Gofer addVersion: has been deprecated. | | Instead of #addVersion: simply use #version: | | | | Hi. Yes, I can reproduce this problem :( | | | | | | | | | | | | | | | | | | Select Proceed to continue, or close this window to cancel the | | operation." | | | | | | I proceed this warrning. | | | | | | Then gived back an error message, I think this error came from the | | Metacello. | | | | I attached the PharoDebug file. | | | | | | | | | | The error is in the method #updateProject where it does: | | | | (GoferPackageReference name: mgr packageName repository: mgr | | repositoryGroup) versionReference. | | | | GoferPackageReference dnu #name:repository: instead, it is | | implemented in GoferResolvedReference | | | | | | Dale any idea? | | | | Versions: Gofer-Core-StephaneDucasse.135. | | Metacello version is ...... ConfigurationOfMetacello project | | currentVersion raises dnu #setName | | | | So...I guess Pharo 1.4 is using a very new version of Gofer, which | | brings lot of changes that break Metacello ? | | | | Thanks! | | | | | | | | | | | | | | | | | | Byte | | Laszlo Zsolt | | | | | | Ps: the image is clean #14112 and the CogVM is the last.. | | | | | | inez Peck < marianopeck(a)gmail.com > | | | | | | | | | | | | | | | | | | | | On Tue, Aug 30, 2011 at 9:53 AM, Laszlo Zsolt Kiss < | | lzskiss(a)gmail.com > wrote: | | | | | | Hi Developers! | | | | | | Can I use any way this combination: DBXTalk with Pharo 1.4? | | | | Hi. Yes, sure. Did you try it? You shouldn't have any problem. | | Please let us know if you do have. | | | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | | | | | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | |

Aug. 30, 2011

Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalkand Pharo 1.4

by Laszlo Zsolt Kiss

hi.I tested this.First load the: Â 'Metacello-Base-DaleHenrichs.19' 'Metacello-Core-DaleHenrichs.455' 'Metacello-MC-DaleHenrichs.505' then: Gofer itÂ Â squeaksource: 'MetacelloRepository';Â Â package: 'ConfigurationOfOpenDBXDriver';Â Â load. then: ((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) project version: '1.0') Â load. I gived just two warnings, after I proceed these warnings the DBXTalk was loaded to the 1.4 #14112 image.Not the nice solution, but working with the 1.4.I tested with the Firebird 2.5 on the Win32 platform. Best regards. Laszlo Zsolt ----- Original Message ----- From: Pharo-project(a)lists.gforge.inria.fr To: Cc: Sent:Tue, 30 Aug 2011 14:26:28 -0700 (PDT) Subject:Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk and Pharo 1.4 Mariano, I think that addVersion: is very old gofer/metacello code ... not fancy new code. It sounds like an old version of Metacello is being loaded/bootstrapped. #addVersion: isn't sent from the current code base ... At a minimum, you should have these packages loaded: 'Metacello-Base-DaleHenrichs.19' 'Metacello-Core-DaleHenrichs.455' 'Metacello-MC-DaleHenrichs.505' if the bootstrapping process is working. Keep in mind that pharo1.4.x has not yet been defined in Metacello (see Issue 4613[1]), so there will be other Metacello issues in 1.4 for the moment ... the proposed bugfix in 4613 would mean that a new version of Metacello would no longer be needed to define the platform specific attributes ... Dale [1] http://code.google.com/p/pharo/issues/detail?id=4613 [1] ----- Original Message ----- | From: "Mariano Martinez Peck" | To: dbxtalk(a)googlegroups.com [3], "Pharo Development" | Sent: Tuesday, August 30, 2011 2:00:26 PM | Subject: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk and Pharo 1.4 | | | | | On Tue, Aug 30, 2011 at 9:14 PM, Laszlo Zsolt Kiss < | lzskiss(a)gmail.com [5] > wrote: | | | | | hi. | first i load the ConfigurationOfOpenDBX and the 1.4 version is | missing from the spec.: | | | | stable: spec | | | spec for: #'pharo12.x' version: '1.0'. | spec for: #'pharo1.3.x' version: '1.0'. | | | then i added the next line to the spec: | | | spec for: #'pharo1.4.x' version: '1.0'. | | | then i probally do it this: | | | (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: | #project) perform: #version: with: #stable) load. | | | i gived back a warring: | | | | "The method Gofer addVersion: has been deprecated. | Instead of #addVersion: simply use #version: | | Hi. Yes, I can reproduce this problem :( | | | | | | | | | Select Proceed to continue, or close this window to cancel the | operation." | | | I proceed this warrning. | | | Then gived back an error message, I think this error came from the | Metacello. | | I attached the PharoDebug file. | | | | | The error is in the method #updateProject where it does: | | (GoferPackageReference name: mgr packageName repository: mgr | repositoryGroup) versionReference. | | GoferPackageReference dnu #name:repository: instead, it is | implemented in GoferResolvedReference | | | Dale any idea? | | Versions: Gofer-Core-StephaneDucasse.135. | Metacello version is ...... ConfigurationOfMetacello project | currentVersion raises dnu #setName | | So...I guess Pharo 14 is using a very new version of Gofer, which | brings lot of changes that break Metacello ? | | Thanks! | | | | | | | | | Byte | Laszlo Zsolt | | | Ps: the image is clean #14112 and the CogVM is the last.. | | | inez Peck < marianopeck(a)gmail.com [6] > | | | | | | | | | | On Tue, Aug 30, 2011 at 9:53 AM, Laszlo Zsolt Kiss < | lzskiss(a)gmail.com [7] > wrote: | | | Hi Developers! | | | Can I use any way this combination: DBXTalk with Pharo 1.4? | | Hi. Yes, sure. Did you try it? You shouldn't have any problem. | Please let us know if you do have. | | | -- | Mariano | http://marianopeck.wordpress.com [8] | | | | | | -- | Mariano | http://marianopeck.wordpress.com [9] | | Links: ------ [1] http://code.google.com/p/pharo/issues/detail?id=4613 [2] mailto:marianopeck@gmail.com [3] mailto:dbxtalk@googlegroups.com [4] mailto:pharo-project@lists.gforge.inria.fr [5] mailto:lzskiss@gmail.com [6] mailto:marianopeck@gmailcom [7] mailto:lzskiss@gmail.com [8] http://marianopeck.wordpress.com [9] http://marianopeck.wordpress.com

Aug. 30, 2011

Re: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk and Pharo 1.4

by Dale Henrichs

Mariano, I think that addVersion: is very old gofer/metacello code ... not fancy new code. It sounds like an old version of Metacello is being loaded/bootstrapped. #addVersion: isn't sent from the current code base ... At a minimum, you should have these packages loaded: 'Metacello-Base-DaleHenrichs.19' 'Metacello-Core-DaleHenrichs.455' 'Metacello-MC-DaleHenrichs.505' if the bootstrapping process is working. Keep in mind that pharo1.4.x has not yet been defined in Metacello (see Issue 4613[1]), so there will be other Metacello issues in 1.4 for the moment ... the proposed bugfix in 4613 would mean that a new version of Metacello would no longer be needed to define the platform specific attributes ... Dale [1] http://code.google.com/p/pharo/issues/detail?id=4613 ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: dbxtalk(a)googlegroups.com, "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Tuesday, August 30, 2011 2:00:26 PM | Subject: [Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk and Pharo 1.4 | | | | | On Tue, Aug 30, 2011 at 9:14 PM, Laszlo Zsolt Kiss < | lzskiss(a)gmail.com > wrote: | | | | | hi. | first i load the ConfigurationOfOpenDBX and the 1.4 version is | missing from the spec.: | | | | stable: spec | <symbolicVersion: #stable> | | spec for: #'pharo1.2.x' version: '1.0'. | spec for: #'pharo1.3.x' version: '1.0'. | | | then i added the next line to the spec: | | | spec for: #'pharo1.4.x' version: '1.0'. | | | then i probally do it this: | | | (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: | #project) perform: #version: with: #stable) load. | | | i gived back a warring: | | | | "The method Gofer addVersion: has been deprecated. | Instead of #addVersion: simply use #version: | | Hi. Yes, I can reproduce this problem :( | | | | | | | | | Select Proceed to continue, or close this window to cancel the | operation." | | | I proceed this warrning. | | | Then gived back an error message, I think this error came from the | Metacello. | | I attached the PharoDebug file. | | | | | The error is in the method #updateProject where it does: | | (GoferPackageReference name: mgr packageName repository: mgr | repositoryGroup) versionReference. | | GoferPackageReference dnu #name:repository: instead, it is | implemented in GoferResolvedReference | | | Dale any idea? | | Versions: Gofer-Core-StephaneDucasse.135. | Metacello version is ...... ConfigurationOfMetacello project | currentVersion raises dnu #setName | | So...I guess Pharo 1.4 is using a very new version of Gofer, which | brings lot of changes that break Metacello ? | | Thanks! | | | | | | | | | Byte | Laszlo Zsolt | | | Ps: the image is clean #14112 and the CogVM is the last.. | | | inez Peck < marianopeck(a)gmail.com > | | | | | | | | | | On Tue, Aug 30, 2011 at 9:53 AM, Laszlo Zsolt Kiss < | lzskiss(a)gmail.com > wrote: | | | Hi Developers! | | | Can I use any way this combination: DBXTalk with Pharo 1.4? | | Hi. Yes, sure. Did you try it? You shouldn't have any problem. | Please let us know if you do have. | | | -- | Mariano | http://marianopeck.wordpress.com | | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

Aug. 30, 2011

[Pharo-project] Gofer/Metacello problem in 1.4 [WAS] Re: DBXTalk and Pharo 1.4

by Mariano Martinez Peck

On Tue, Aug 30, 2011 at 9:14 PM, Laszlo Zsolt Kiss <lzskiss(a)gmail.com>wrote: > hi. > first i load the ConfigurationOfOpenDBX and the 1.4 version is missing from > the spec.: > > stable: spec > <symbolicVersion: #stable> > > spec for: #'pharo1.2.x' version: '1.0'. > spec for: #'pharo1.3.x' version: '1.0'. > > then i added the next line to the spec: > > spec for: #'pharo1.4.x' version: '1.0'. > > then i probally do it this: > > (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: #project) > perform: #version: with: #stable) load. > > i gived back a warring: > > "The method Gofer addVersion: has been deprecated. > Instead of #addVersion: simply use #version: > Hi. Yes, I can reproduce this problem :( > > Select Proceed to continue, or close this window to cancel the operation." > > I proceed this warrning. > > Then gived back an error message, I think this error came from the > Metacello. > I attached the PharoDebug file. > > The error is in the method #updateProject where it does: (GoferPackageReference name: mgr packageName repository: mgr repositoryGroup) versionReference. GoferPackageReference dnu #name:repository: instead, it is implemented in GoferResolvedReference Dale any idea? Versions: Gofer-Core-StephaneDucasse.135. Metacello version is ...... ConfigurationOfMetacello project currentVersion raises dnu #setName So...I guess Pharo 1.4 is using a very new version of Gofer, which brings lot of changes that break Metacello ? Thanks! Byte > Laszlo Zsolt > > Ps: the image is clean #14112 and the CogVM is the last.. > > inez Peck <marianopeck(a)gmail.com> > >> >> >> On Tue, Aug 30, 2011 at 9:53 AM, Laszlo Zsolt Kiss <lzskiss(a)gmail.com>wrote: >> >>> Hi Developers! >>> >>> Can I use any way this combination: DBXTalk with Pharo 1.4? >>> >> >> Hi. Yes, sure. Did you try it? You shouldn't have any problem. >> Please let us know if you do have. >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Aug. 30, 2011

Re: [Pharo-project] Website RSS feed broken?

by Mariano Martinez Peck

Hi Stefan, I've noticed the same problem :( On Tue, Aug 30, 2011 at 10:41 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > Every single time a new news item gets posted on the pharo website, Google > Reader reports some old items as being new. > When looking at the RSS content itself, there does not immediately stick > anything out as broken. > But still, since this happens every time, and only with the Pharo web page, > I assume you got at bug somewhere. > Perhaps the guid's of the posts are not stable? > > Best regards > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Mariano http://marianopeck.wordpress.com

Aug. 30, 2011

[Pharo-project] Website RSS feed broken?

by Stefan Marr

Hi: Every single time a new news item gets posted on the pharo website, Google Reader reports some old items as being new. When looking at the RSS content itself, there does not immediately stick anything out as broken. But still, since this happens every time, and only with the Pharo web page, I assume you got at bug somewhere. Perhaps the guid's of the posts are not stable? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by StÃ©phane Ducasse

My suggestion is the following one: we could add it because there is value: now I would not use it in the core of the system. I hope that one of these days we will be able to bootstrap and identify a kernel and after that we could tag a bit the methods in terms of layers. Stef On Aug 30, 2011, at 9:14 PM, StÃ©phane Ducasse wrote: > Indeed I would prefer just to have perform: and block value: > > Stef > > On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote: > >> Therefor I suggested to remove Symbol>>#value: the last time this was >> brought up. >> >> If you keep it, besides all the variations of #value:... you also need >> to consider #cull:, #cull:cull:, #cull:cull:cull:, >> #valueWithArguments:, valueWithEnoughArguments:, >> #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as >> somebody needs to fix #numArgs (which is highly inconsistent with a >> block that has the same behavior). >> >> Also for many asymmetric selectors the trick does not work (e.g. >> #join:, #matches:, #includesSubString:, ...) because you need to turn >> around the arguments. >> >> Aside from the above, evaluable selectors hamper readability: Back in >> 2005 Magritte added #value: and #value:value: as method extensions. >> You can go and read all the mails of people having troubles reading >> the code. The benefit of writing a few characters less is really not >> worth the trouble spent digesting the code. >> >> Lukas >> >> On 30 August 2011 20:09, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>> It's a question of consistency. Why support value:, but not value:value:? >>> >>> Niko >>> >>> On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 30 August 2011 18:02, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: >>>>> On 30/08/2011 13:30, Tudor Girba wrote: >>>>> >>>>> I proposed this some one or two years ago. I got shut down, but I still find >>>>> it a good idea. >>>>> >>>>> And I even have a semantic reason: >>>>> - A Block represents a piece of functionality that can be evaluated with >>>>> some input >>>>> - A Symbol often represents a selector which in turns represents a piece of >>>>> functionality that can be evaluated with some input. >>>>> >>>>> I seem to recall there was discussion some time ago about splitting Selector >>>>> functionality from Symbol. After all, there's no real reason that a selector >>>>> has to be a Symbol. >>>>> >>>> >>>> Selector is just a role to identify a method in method's dictionary. >>>> It can be any object: if you look how VM does a lookup >>>> there's nothing which limits a selectors to be the instances of Symbol >>>> (perhaps the only thing is printing a stack trace ;). >>>> >>>> What i mean that any object may be a selector: >>>> >>>> MyClass methodDict at: 1 put: someMethod. >>>> >>>> MyClass new perform: 1 >>>> >>>> should work. >>>> >>>> So, i don't see what you can gain by splitting functionality of >>>> Selector from Symbol. Then you should put all selector-related >>>> protocol to Object class. >>>> And this even worse idea :) >>>> >>>> >>>>> Also, some of the examples in this thread seem to be about terseness for >>>>> terseness sake. >>>>> >>>> >>>> Yeah. I have same impression. >>>> But its cool :) >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>> >>> >>> >>> -- >>> http://scg.unibe.ch/staff/Schwarz >>> twitter.com/nes1983 >>> Tel: +41786126354 >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > >

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by StÃ©phane Ducasse

Indeed I would prefer just to have perform: and block value: Stef On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote: > Therefor I suggested to remove Symbol>>#value: the last time this was > brought up. > > If you keep it, besides all the variations of #value:... you also need > to consider #cull:, #cull:cull:, #cull:cull:cull:, > #valueWithArguments:, valueWithEnoughArguments:, > #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as > somebody needs to fix #numArgs (which is highly inconsistent with a > block that has the same behavior). > > Also for many asymmetric selectors the trick does not work (e.g. > #join:, #matches:, #includesSubString:, ...) because you need to turn > around the arguments. > > Aside from the above, evaluable selectors hamper readability: Back in > 2005 Magritte added #value: and #value:value: as method extensions. > You can go and read all the mails of people having troubles reading > the code. The benefit of writing a few characters less is really not > worth the trouble spent digesting the code. > > Lukas > > On 30 August 2011 20:09, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> It's a question of consistency. Why support value:, but not value:value:? >> >> Niko >> >> On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 30 August 2011 18:02, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: >>>> On 30/08/2011 13:30, Tudor Girba wrote: >>>> >>>> I proposed this some one or two years ago. I got shut down, but I still find >>>> it a good idea. >>>> >>>> And I even have a semantic reason: >>>> - A Block represents a piece of functionality that can be evaluated with >>>> some input >>>> - A Symbol often represents a selector which in turns represents a piece of >>>> functionality that can be evaluated with some input. >>>> >>>> I seem to recall there was discussion some time ago about splitting Selector >>>> functionality from Symbol. After all, there's no real reason that a selector >>>> has to be a Symbol. >>>> >>> >>> Selector is just a role to identify a method in method's dictionary. >>> It can be any object: if you look how VM does a lookup >>> there's nothing which limits a selectors to be the instances of Symbol >>> (perhaps the only thing is printing a stack trace ;). >>> >>> What i mean that any object may be a selector: >>> >>> MyClass methodDict at: 1 put: someMethod. >>> >>> MyClass new perform: 1 >>> >>> should work. >>> >>> So, i don't see what you can gain by splitting functionality of >>> Selector from Symbol. Then you should put all selector-related >>> protocol to Object class. >>> And this even worse idea :) >>> >>> >>>> Also, some of the examples in this thread seem to be about terseness for >>>> terseness sake. >>>> >>> >>> Yeah. I have same impression. >>> But its cool :) >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41786126354 >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 30, 2011

Re: [Pharo-project] Symbol>value:

by StÃ©phane Ducasse

On Aug 30, 2011, at 6:02 PM, Douglas Brebner wrote: > On 30/08/2011 13:30, Tudor Girba wrote: >> I proposed this some one or two years ago. I got shut down, but I still find it a good idea. >> >> And I even have a semantic reason: >> - A Block represents a piece of functionality that can be evaluated with some input >> - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input. >> > > I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol. It was just a stupid idea of mine :) > > Also, some of the examples in this thread seem to be about terseness for terseness sake. >

Aug. 30, 2011