On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
What's wrong with a dependency on System?
Is your overall goal to completely remove System from the system?
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 21 Nov 2013, at 22:58, Chris Muller asqueaker@gmail.com wrote:
What's wrong with a dependency on System?
Because a dependency on system is a dependency on everything that system depends on... which is most of the image.
Is your overall goal to completely remove System from the system?
Not really. I want to give it a serious hair trim and break it up into pieces that make sense. Right now it's a bucket of things, without a coherent story. When you reply to this saying "it's the smalltalk environment" my reply is "no, the image is". System is the God Class antipattern applied to packages.
frank
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
Here's the opening of that discussion:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/165845...
On Thu, Nov 21, 2013 at 5:05 PM, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On Thu, 21 Nov 2013, Chris Muller wrote:
Here's the opening of that discussion:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/165845...
On Thu, Nov 21, 2013 at 5:05 PM, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
So more than a year has passed, but it seems to me that there's no demand for anything more than extracting the functionality from Utilities. Also, there are two fields: initials and name. And if those are held in a single object, then swapping them is simpler, which would be useful while running the tests.
Levente
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.
frank
On 21 Nov 2013, at 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 22 November 2013 08:29, Frank Shearar frank.shearar@gmail.com wrote:
It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.
I sound like a rude, grumpy old man. I don't mean to sound _rude_ :) So I'll go re-re-read the last round of discussion, and make sure I'm not deliberately snubbing anyone's ideas, and deliver some code. Hopefully it won't be a complete disaster, but in order to fix this problem, _someone_ has to write something. So I'll take the hit, and put my code up for tomato-throwing.
frank
frank
On 21 Nov 2013, at 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On Fri, 22 Nov 2013, Frank Shearar wrote:
It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.
Will your implementation be any different than what mine was?
Levente
frank
On 21 Nov 2013, at 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 22 November 2013 10:44, Levente Uzonyi leves@elte.hu wrote:
On Fri, 22 Nov 2013, Frank Shearar wrote:
It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.
Will your implementation be any different than what mine was?
Seeing as I didn't finish anything on the train this morning, I'd far rather just use your implementation. Did you adjust the API to fit Colin's comments about #username?
It looks like you've already done the work. I'm happy to be the one to ram it through trunk.
frank
Levente
frank
On 21 Nov 2013, at 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 22 November 2013 10:53, Frank Shearar frank.shearar@gmail.com wrote:
On 22 November 2013 10:44, Levente Uzonyi leves@elte.hu wrote:
On Fri, 22 Nov 2013, Frank Shearar wrote:
It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.
Will your implementation be any different than what mine was?
Seeing as I didn't finish anything on the train this morning, I'd far rather just use your implementation. Did you adjust the API to fit Colin's comments about #username?
It looks like you've already done the work. I'm happy to be the one to ram it through trunk.
The only thing I don't like is the class-side replication of the instance-side protocol. I'd rather just have a #current (which is there already).
frank
frank
Levente
frank
On 21 Nov 2013, at 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 22 November 2013 16:10, Frank Shearar frank.shearar@gmail.com wrote:
On 22 November 2013 10:53, Frank Shearar frank.shearar@gmail.com wrote:
On 22 November 2013 10:44, Levente Uzonyi leves@elte.hu wrote:
On Fri, 22 Nov 2013, Frank Shearar wrote:
It's been over a year, and several rounds of discussion. The last round fizzled out with 'yeah ok we should do it but don't call it Author'. Really, I don't particularly care _what_ we do as long as we remove another part of Utilities. So I'm going to write a minimal thing that pulls the state out of Utilities, where it never belonged. Once the real problem - that state - has been addressed, finessing the API will be much easier.
Will your implementation be any different than what mine was?
Seeing as I didn't finish anything on the train this morning, I'd far rather just use your implementation. Did you adjust the API to fit Colin's comments about #username?
It looks like you've already done the work. I'm happy to be the one to ram it through trunk.
The only thing I don't like is the class-side replication of the instance-side protocol. I'd rather just have a #current (which is there already).
The thing is, this singleton-ness makes the tests really messy, in that they monkey around with global state. Why can't we allow the #new and work with test instances, throw away the setters, and have a functional style SystemAuthor that we entirely replace when we need to?
frank
frank
frank
Levente
frank
On 21 Nov 2013, at 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote: > > Frank Shearar uploaded a new version of MonticelloConfigurations to > project The Trunk: > http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz > > ==================== Summary ==================== > > Name: MonticelloConfigurations-fbs.118 > Author: fbs > Time: 21 November 2013, 9:20:19.085 pm > UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 > Ancestors: MonticelloConfigurations-cmm.117 > > Move the #upgradeIsMerge preference to MCConfiguration. > > =============== Diff against MonticelloConfigurations-cmm.117 > ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 21 November 2013 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
We cannot take proper advantage of it because it doesn't exist yet :)
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117 ===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
Hi Frank,
On 11/22/2013 11:09 AM, Frank Shearar wrote:
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
I think overrides (a la VW, but they could be done even better) could solve these entanglement problems much easier (after the initial investment), directly attacking modularity and helping address other issues in this area: loading/unloading, minimal image, versioning.
Florin
Hi Florin,
On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc florin.mateoc@gmail.comwrote:
Hi Frank,
On 11/22/2013 11:09 AM, Frank Shearar wrote:
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
I think overrides (a la VW, but they could be done even better)
+1. I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.h... a better approach to implementation. Does it make sense to you?
could solve these entanglement problems much easier (after the initial investment), directly attacking modularity and helping address other issues in this area: loading/unloading, minimal image, versioning.
Florin
Hi Eliot,
On 11/26/2013 7:15 PM, Eliot Miranda wrote:
Hi Florin,
On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc <florin.mateoc@gmail.com mailto:florin.mateoc@gmail.com> wrote:
I think overrides (a la VW, but they could be done even better)+1. I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.h... for a better approach to implementation. Does it make sense to you?
could solve these entanglement problems much easier (after the initial investment), directly attacking modularity and helping address other issues in this area: loading/unloading, minimal image, versioning. Florin-- best, Eliot
I actually liked overrides a lot - I should have emphasized that (especially that there are seemingly so many things that I don't like :) - must be the age). It was, from my point of view, the one saving grace for Store (as compared to Envy, which was otherwise fantastic (and it had atomic loading).
I am sorry, I did not really understand your alternative approach from that message. What I had in mind was, on one hand, to remove any restrictions for what an override can do (I don't remember exactly, but I think there were some unnecessary restrictions), on the other hand, specify in the override itself what it expects the overidee to be. These override expectations should be in the form of source code (method formatted source, class structure...), not versions or some such. The fact that the override specifies its expectations not only makes it likely that it will work when they are met, but also implies that they were tested in that configuration by their developer. The expectations for each override should be a collection, not a single source, since this would allow to load multiple packages that override the same things. One of the expectations would be the base variation, another would be after a known other package overrode it...
Cheers, Florin
On 11/27/2013 12:21 AM, Florin Mateoc wrote:
Hi Eliot,
On 11/26/2013 7:15 PM, Eliot Miranda wrote:
Hi Florin,
On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc <florin.mateoc@gmail.com mailto:florin.mateoc@gmail.com> wrote:
I think overrides (a la VW, but they could be done even better)+1. I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.h... for a better approach to implementation. Does it make sense to you?
could solve these entanglement problems much easier (after the initial investment), directly attacking modularity and helping address other issues in this area: loading/unloading, minimal image, versioning. Florin-- best, Eliot
I actually liked overrides a lot - I should have emphasized that (especially that there are seemingly so many things that I don't like :) - must be the age). It was, from my point of view, the one saving grace for Store (as compared to Envy, which was otherwise fantastic (and it had atomic loading).
I am sorry, I did not really understand your alternative approach from that message. What I had in mind was, on one hand, to remove any restrictions for what an override can do (I don't remember exactly, but I think there were some unnecessary restrictions), on the other hand, specify in the override itself what it expects the overidee to be. These override expectations should be in the form of source code (method formatted source, class structure...), not versions or some such. The fact that the override specifies its expectations not only makes it likely that it will work when they are met, but also implies that they were tested in that configuration by their developer. The expectations for each override should be a collection, not a single source, since this would allow to load multiple packages that override the same things. One of the expectations would be the base variation, another would be after a known other package overrode it...
Cheers, Florin
Just a couple of clarifications, I may have been too succinct. I would call this structural matching for projects insetad of nominal and it seems much more robust. You match more on semantics (code) rather than some convention, where the match can fail because a project bumped its version number only to add a readme. Also notice how this also makes order of project loading irrelevant, as it should be. Of course, sometimes projects do depend/build on each other, and that would be reflected in the overrides expectations - the order would be imposed, potentially automatically, by what is in the overrides and their expectations - but when they just happen to clash on some overrides, order is irrelevant. In such situations, it is enough for one project to be aware of the other one, and they can be loaded in whatever order. Say project A overrides method m from base, but is aware that sometimes people also have project B loaded, which also overrides method m. Then A can be loaded whether B is loaded or not. B can also be loaded, even if A is already loaded, since it "sees" that method m expects its own variation of method m, so it can rely on project A's variation instead (this may mean that the override itself, not just its expectations, has several incarnations, depending on what it finds already loaded)
Florin
On 27.11.2013, at 01:15, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Florin,
On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc florin.mateoc@gmail.com wrote: Hi Frank,
On 11/22/2013 11:09 AM, Frank Shearar wrote:
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
I think overrides (a la VW, but they could be done even better)
+1. I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.h... for a better approach to implementation. Does it make sense to you?
There is code mentioned in that reference. I would love to see something there :)
A good overriding (or shall we say method shadowing?) system would ease transitions in the trunk enormously, I would say. _Then_ we could define Some minimal packages (say the Core), which other, more sophisticated packages can override/shadow (say, Kernel, Objects[not yet existent], Collections)
Best -Tobias
We're talking about two things here. 1) Whittling Utilities down by removing AuthorInitials and AuthorName so Utilities can approach it's demise. We all agree on this.
And, 2) Where to put them.
Given Levente's reminder that we do in fact, have TWO fields, not just one, I suppose that pushes me over the edge from Smalltalk authorInitials to a new SystemAuthor singleton afterall. I wouldn't want to have Smalltalk authorInitials AND Smalltalk authorName.
WAIT! Let's consider one final option. *Removal* of authorName. When I look at senders I see users that are mostly app-specific. Etoys, saving a TextStyle or Postscript object... That seems pretty weak to me for inclusion in a core image plus the introduction of a new SystemAuthor class.
What do you guys think?
On Fri, Nov 22, 2013 at 10:09 AM, Frank Shearar frank.shearar@gmail.comwrote:
On 21 November 2013 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
We cannot take proper advantage of it because it doesn't exist yet :)
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com
wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to
project The Trunk:
http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117
===============
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
On 22 November 2013 16:37, Chris Muller ma.chris.m@gmail.com wrote:
We're talking about two things here. 1) Whittling Utilities down by removing AuthorInitials and AuthorName so Utilities can approach it's demise. We all agree on this.
And, 2) Where to put them.
Given Levente's reminder that we do in fact, have TWO fields, not just one, I suppose that pushes me over the edge from Smalltalk authorInitials to a new SystemAuthor singleton afterall. I wouldn't want to have Smalltalk authorInitials AND Smalltalk authorName.
WAIT! Let's consider one final option. *Removal* of authorName. When I look at senders I see users that are mostly app-specific. Etoys, saving a TextStyle or Postscript object... That seems pretty weak to me for inclusion in a core image plus the introduction of a new SystemAuthor class.
What do you guys think?
I would not cry if we removed authorName, or made it simply an alias for authorInitials. I do want it a separate class though, because it's a separate entity. It's not just a string, after all: it's a string with setup logic, and asking the user for stuff. I've made classes for less than that, many times.
frank
On Fri, Nov 22, 2013 at 10:09 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
We cannot take proper advantage of it because it doesn't exist yet :)
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
WAIT! Let's consider one final option. *Removal* of authorName. When I
look at senders I see users that are mostly app-specific. Etoys, saving
a
TextStyle or Postscript object... That seems pretty weak to me for inclusion in a core image plus the introduction of a new SystemAuthor
class.
What do you guys think?
I would not cry if we removed authorName, or made it simply an alias for authorInitials. I do want it a separate class though, because it's a separate entity. It's not just a string, after all: it's a string with setup logic, and asking the user for stuff. I've made classes for less than that, many times.
"Separate entity", alone, is not enough. I used to develop code this way; "ultimate objects" that matched the real-life semantic structure.
So if I had a Person object with a 'name', I would *never even consider" letting its 'name' be a simple String, it had to be a first-class Name object with #first, #middle, #last, and printing methods, etc.
Then, one day, I found myself with all of this "stuff" that wasn't really needed. More methods, more classes, more concepts, more layers, more reads by the database. NONE of which, is truly needed. It was "heavyweight" instead of TSTTCPW.
Since then, I've realized, it's perfectly fine to not have a first-class object if all you need is a String.
frank
On Fri, Nov 22, 2013 at 10:09 AM, Frank Shearar <frank.shearar@gmail.com
wrote:
On 21 November 2013 23:05, Chris Muller asqueaker@gmail.com wrote:
Back when Levente approached this, we had a detailed discussion about it. I think we should all go back and read that before introducing a SystemAuthor class.
Personally, I wouldn't mind just having
Smalltalk authorInitials "answers a String"
until we decide we need to support multiple concurrent Author objects with more than just name and initials..
And this makes sense anyway -- Smalltalk's current #author.
I struggle with having a whole class (SystemAuthor) when we cannot take proper advantage of it and only really need one String field at this time, not a heavy-weight, value-holder singleton.
We cannot take proper advantage of it because it doesn't exist yet :)
I'd rather waste an entire class and kill Utilities, than have Utilities continually stick a spanner in the more important objective of modularity.
First Utilities, then the world!
frank
On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar <
frank.shearar@gmail.com>
wrote:
On 21 November 2013 21:20, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
==================== Summary ====================
Name: MonticelloConfigurations-fbs.118 Author: fbs Time: 21 November 2013, 9:20:19.085 pm UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571 Ancestors: MonticelloConfigurations-cmm.117
Move the #upgradeIsMerge preference to MCConfiguration.
=============== Diff against MonticelloConfigurations-cmm.117
Just by the way, MonticelloConfigurations depends on System for one thing only now: Utilities' author stuff. I'm knocking up a completely lame minimal mimic-existing-stuff SystemAuthor that I will hopefully finish tomorrow. I plan to sever this dependency, and then remove all the references to Utilities authorName/Initials with SystemAuthor current, and then we can think about any other stuff we might do with this.
frank
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Eliot Miranda -
Florin Mateoc -
Frank Shearar -
Levente Uzonyi -
Tobias Pape