Tobias Pape uploaded a new version of Environments to project The Trunk:
http://source.squeak.org/trunk/Environments-topa.56.mcz ==================== Summary ==================== Name: Environments-topa.56 Author: topa Time: 22 January 2015, 12:48:30.677 am UUID: e5cad590-2869-4f02-84ac-482952779d06 Ancestors: Environments-topa.55 Provide more Dictionary protocol for exisiting users of Smalltalk globals. =============== Diff against Environments-topa.55 =============== Item was added: + ----- Method: Environment>>associationsDo: (in category 'emulating') ----- + associationsDo: aBlock + "Evaluate aBlock for each of the receiver's elements (key/value associations)." + + declarations associationsDo: aBlock! Item was changed: ----- Method: Environment>>do: (in category 'emulating') ----- do: aBlock "Evaluate aBlock for each of the receiver's values." + self valuesDo: aBlock! - declarations valuesDo: aBlock! Item was added: + ----- Method: Environment>>keysAndValuesDo: (in category 'emulating') ----- + keysAndValuesDo: aBlock + ^self associationsDo: [:assoc | + aBlock value: assoc key value: assoc value].! Item was added: + ----- Method: Environment>>valuesDo: (in category 'emulating') ----- + valuesDo: aBlock + "Evaluate aBlock for each of the receiver's values." + + declarations valuesDo: aBlock! |
On 21 January 2015 at 23:48, <[hidden email]> wrote:
> Tobias Pape uploaded a new version of Environments to project The Trunk: > http://source.squeak.org/trunk/Environments-topa.56.mcz > > ==================== Summary ==================== > > Name: Environments-topa.56 > Author: topa > Time: 22 January 2015, 12:48:30.677 am > UUID: e5cad590-2869-4f02-84ac-482952779d06 > Ancestors: Environments-topa.55 > > Provide more Dictionary protocol for exisiting users of Smalltalk globals. If it addresses, in an expedient way, existing problems, then fine. But the Environments work was explicitly trying to move _away_ from the Dictionary protocols. Hence why the existing Dictionary-like methods are in the "emulating" category. frank |
On 22.01.2015, at 09:22, Frank Shearar <[hidden email]> wrote: > On 21 January 2015 at 23:48, <[hidden email]> wrote: >> Tobias Pape uploaded a new version of Environments to project The Trunk: >> http://source.squeak.org/trunk/Environments-topa.56.mcz >> >> ==================== Summary ==================== >> >> Name: Environments-topa.56 >> Author: topa >> Time: 22 January 2015, 12:48:30.677 am >> UUID: e5cad590-2869-4f02-84ac-482952779d06 >> Ancestors: Environments-topa.55 >> >> Provide more Dictionary protocol for exisiting users of Smalltalk globals. > > If it addresses, in an expedient way, existing problems, then fine. > But the Environments work was explicitly trying to move _away_ from > the Dictionary protocols. Hence why the existing Dictionary-like > methods are in the "emulating" category. Refactoring-Core is using this API. Best -Tobias |
On 22 January 2015 at 08:25, Tobias Pape <[hidden email]> wrote:
> > On 22.01.2015, at 09:22, Frank Shearar <[hidden email]> wrote: > >> On 21 January 2015 at 23:48, <[hidden email]> wrote: >>> Tobias Pape uploaded a new version of Environments to project The Trunk: >>> http://source.squeak.org/trunk/Environments-topa.56.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Environments-topa.56 >>> Author: topa >>> Time: 22 January 2015, 12:48:30.677 am >>> UUID: e5cad590-2869-4f02-84ac-482952779d06 >>> Ancestors: Environments-topa.55 >>> >>> Provide more Dictionary protocol for exisiting users of Smalltalk globals. >> >> If it addresses, in an expedient way, existing problems, then fine. >> But the Environments work was explicitly trying to move _away_ from >> the Dictionary protocols. Hence why the existing Dictionary-like >> methods are in the "emulating" category. > > Refactoring-Core is using this API. Obviously making the rest of the world move to the Environments API is the _right_ thing to do, if it's manipulating environmental stuff, but in the meantime, +1 to this addition :) frank > Best > -Tobias > |
2015-01-22 9:30 GMT+01:00 Frank Shearar <[hidden email]>:
We can use the #deprecated: in the meantime so as to not forget - that we should change senders - that we should not use this API in new code > Best |
On 22.01.2015, at 18:32, Nicolas Cellier <[hidden email]> wrote: > > > 2015-01-22 9:30 GMT+01:00 Frank Shearar <[hidden email]>: > On 22 January 2015 at 08:25, Tobias Pape <[hidden email]> wrote: > > > > On 22.01.2015, at 09:22, Frank Shearar <[hidden email]> wrote: > > > >> On 21 January 2015 at 23:48, <[hidden email]> wrote: > >>> Tobias Pape uploaded a new version of Environments to project The Trunk: > >>> http://source.squeak.org/trunk/Environments-topa.56.mcz > >>> > >>> ==================== Summary ==================== > >>> > >>> Name: Environments-topa.56 > >>> Author: topa > >>> Time: 22 January 2015, 12:48:30.677 am > >>> UUID: e5cad590-2869-4f02-84ac-482952779d06 > >>> Ancestors: Environments-topa.55 > >>> > >>> Provide more Dictionary protocol for exisiting users of Smalltalk globals. > >> > >> If it addresses, in an expedient way, existing problems, then fine. > >> But the Environments work was explicitly trying to move _away_ from > >> the Dictionary protocols. Hence why the existing Dictionary-like > >> methods are in the "emulating" category. > > > > Refactoring-Core is using this API. > > Obviously making the rest of the world move to the Environments API is > the _right_ thing to do, if it's manipulating environmental stuff, but > in the meantime, +1 to this addition :) > > frank > > > We can use the #deprecated: in the meantime so as to not forget > - that we should change senders > - that we should not use this API in new code I'm unsure. I _really_ like the idea of treating a namespace as a dictionary. But this is just gut feeling. Best -Tobias |
On 22.01.2015, at 18:46, Tobias Pape <[hidden email]> wrote:
> > On 22.01.2015, at 18:32, Nicolas Cellier <[hidden email]> wrote: >> >> We can use the #deprecated: in the meantime so as to not forget >> - that we should change senders >> - that we should not use this API in new code > > I'm unsure. > I _really_ like the idea of treating a namespace as a dictionary. > But this is just gut feeling. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Tobias Pape
On Thu, Jan 22, 2015 at 11:46 AM, Tobias Pape <[hidden email]> wrote:
> > On 22.01.2015, at 18:32, Nicolas Cellier <[hidden email]> wrote: > >> >> >> 2015-01-22 9:30 GMT+01:00 Frank Shearar <[hidden email]>: >> On 22 January 2015 at 08:25, Tobias Pape <[hidden email]> wrote: >> > >> > On 22.01.2015, at 09:22, Frank Shearar <[hidden email]> wrote: >> > >> >> On 21 January 2015 at 23:48, <[hidden email]> wrote: >> >>> Tobias Pape uploaded a new version of Environments to project The Trunk: >> >>> http://source.squeak.org/trunk/Environments-topa.56.mcz >> >>> >> >>> ==================== Summary ==================== >> >>> >> >>> Name: Environments-topa.56 >> >>> Author: topa >> >>> Time: 22 January 2015, 12:48:30.677 am >> >>> UUID: e5cad590-2869-4f02-84ac-482952779d06 >> >>> Ancestors: Environments-topa.55 >> >>> >> >>> Provide more Dictionary protocol for exisiting users of Smalltalk globals. >> >> >> >> If it addresses, in an expedient way, existing problems, then fine. >> >> But the Environments work was explicitly trying to move _away_ from >> >> the Dictionary protocols. Hence why the existing Dictionary-like >> >> methods are in the "emulating" category. >> > >> > Refactoring-Core is using this API. >> >> Obviously making the rest of the world move to the Environments API is >> the _right_ thing to do, if it's manipulating environmental stuff, but >> in the meantime, +1 to this addition :) >> >> frank >> >> >> We can use the #deprecated: in the meantime so as to not forget >> - that we should change senders >> - that we should not use this API in new code > > I'm unsure. > I _really_ like the idea of treating a namespace as a dictionary. > But this is just gut feeling. My first reaction was similar to Frank's, but then I remembered that this is Tobias who, I think, has worked on some of the HP's projects like Code Talk and other cool IDE and development tools. That made me more empathetic to Tobias' gut feeling -- because by being able to have an API consistent with a general collection, it may have facilitated the implementation of some of these tools. So I concluded the "detractor" is not it _having_ Dictionary API, but by _using_ its Dictionary API from other places that could and should use higher-level Environments API. We could simply not do that. |
In reply to this post by Bert Freudenberg
On Thu, Jan 22, 2015 at 12:06 PM, Bert Freudenberg <[hidden email]> wrote:
> On 22.01.2015, at 18:46, Tobias Pape <[hidden email]> wrote: >> >> On 22.01.2015, at 18:32, Nicolas Cellier <[hidden email]> wrote: >>> >>> We can use the #deprecated: in the meantime so as to not forget >>> - that we should change senders >>> - that we should not use this API in new code >> >> I'm unsure. >> I _really_ like the idea of treating a namespace as a dictionary. >> But this is just gut feeling. > > Once we actually use multiple environments, won't we have to modify the tools anyway? It would be a pity if you could only use e.g. the Refactoring tools on the global environment. Why would including the Dictionary API in Smalltalk mean one could "only" use the Refactoring tools? It is no impediment to developing new tools.. |
> On 22.01.2015, at 21:30, Chris Muller <[hidden email]> wrote: > > On Thu, Jan 22, 2015 at 12:06 PM, Bert Freudenberg <[hidden email]> wrote: >> On 22.01.2015, at 18:46, Tobias Pape <[hidden email]> wrote: >>> >>> On 22.01.2015, at 18:32, Nicolas Cellier <[hidden email]> wrote: >>>> >>>> We can use the #deprecated: in the meantime so as to not forget >>>> - that we should change senders >>>> - that we should not use this API in new code >>> >>> I'm unsure. >>> I _really_ like the idea of treating a namespace as a dictionary. >>> But this is just gut feeling. >> >> Once we actually use multiple environments, won't we have to modify the tools anyway? It would be a pity if you could only use e.g. the Refactoring tools on the global environment. > > Why would including the Dictionary API in Smalltalk mean one could > "only" use the Refactoring tools? It is no impediment to developing > new tools.. An old tool will not know that there is more than one environment. If it has to be made aware of environments anyway, then at the same time it can be made to use the proper API, so we may not need to add the dictionary protocol. OTOH I like polymorphism. I see no good reason to not make the environment expose a dictionary-like protocol, since it clearly associates keys with values, which sounds a lot like a dictionary. But I presume Colin had good reasons to not make this obvious addition, so it may well be that I'm missing something. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Chris Muller-3
On 22 January 2015 at 20:26, Chris Muller <[hidden email]> wrote:
> On Thu, Jan 22, 2015 at 11:46 AM, Tobias Pape <[hidden email]> wrote: >> >> On 22.01.2015, at 18:32, Nicolas Cellier <[hidden email]> wrote: >> >>> >>> >>> 2015-01-22 9:30 GMT+01:00 Frank Shearar <[hidden email]>: >>> On 22 January 2015 at 08:25, Tobias Pape <[hidden email]> wrote: >>> > >>> > On 22.01.2015, at 09:22, Frank Shearar <[hidden email]> wrote: >>> > >>> >> On 21 January 2015 at 23:48, <[hidden email]> wrote: >>> >>> Tobias Pape uploaded a new version of Environments to project The Trunk: >>> >>> http://source.squeak.org/trunk/Environments-topa.56.mcz >>> >>> >>> >>> ==================== Summary ==================== >>> >>> >>> >>> Name: Environments-topa.56 >>> >>> Author: topa >>> >>> Time: 22 January 2015, 12:48:30.677 am >>> >>> UUID: e5cad590-2869-4f02-84ac-482952779d06 >>> >>> Ancestors: Environments-topa.55 >>> >>> >>> >>> Provide more Dictionary protocol for exisiting users of Smalltalk globals. >>> >> >>> >> If it addresses, in an expedient way, existing problems, then fine. >>> >> But the Environments work was explicitly trying to move _away_ from >>> >> the Dictionary protocols. Hence why the existing Dictionary-like >>> >> methods are in the "emulating" category. >>> > >>> > Refactoring-Core is using this API. >>> >>> Obviously making the rest of the world move to the Environments API is >>> the _right_ thing to do, if it's manipulating environmental stuff, but >>> in the meantime, +1 to this addition :) >>> >>> frank >>> >>> >>> We can use the #deprecated: in the meantime so as to not forget >>> - that we should change senders >>> - that we should not use this API in new code >> >> I'm unsure. >> I _really_ like the idea of treating a namespace as a dictionary. >> But this is just gut feeling. > > My first reaction was similar to Frank's, but then I remembered that > this is Tobias who, I think, has worked on some of the HP's projects > like Code Talk and other cool IDE and development tools. > > That made me more empathetic to Tobias' gut feeling -- because by > being able to have an API consistent with a general collection, it may > have facilitated the implementation of some of these tools. > > So I concluded the "detractor" is not it _having_ Dictionary API, but > by _using_ its Dictionary API from other places that could and should > use higher-level Environments API. We could simply not do that. Yes, exactly. frank |
In reply to this post by Tobias Pape
On Thu, Jan 22, 2015 at 9:46 AM, Tobias Pape <[hidden email]> wrote:
To be pedantic, +0.5. I like being able to use the read-only part of the Dictionary protocol on Environments. It is the destructive update-in-place part at:put: et al that shouldn't be supported. Modification is something that Environment needs to control carefgully to maintain system integrity. But this is just gut feeling. best,
Eliot |
> I'm unsure.
> I _really_ like the idea of treating a namespace as a dictionary. > > > To be pedantic, +0.5. I like being able to use the read-only part of > the Dictionary protocol on Environments. It is the destructive > update-in-place part at:put: et al that shouldn't be supported. > Modification is something that Environment needs to control carefgully > to maintain system integrity. Isn't it the tradition of Smalltalk to be able to completely mess the system up by redefining a few methods, or using dangerous ones ? Stef |
In reply to this post by Eliot Miranda-2
If it looks -- e.g. in an object explorer -- like a dictionary, you should be able to talk to it like one. If #at:put: offers no meaningful implementation, throw a descriptive exception. Raising a generic DNU/MNU in such a case may confuse the tool/application developer and hence may repeat such a discussion over and over again. :)
If, some day, we will find a meaningful/safe implementation/semantic for #at:put:, just provide it and stop raising and exception. Best, Marcel |
Isn't there even a way to raise an exception and keep on calling that method?
[env at: #foo put: #bar] on: UnsafeInterfaceException do: [:ex | ex resume]. Should be fine for development tools? So you could provide some implementation and still raise an exception. Best, Marcel |
Free forum by Nabble | Edit this page |