Re: Thinking about Environments
Locked
Re: Thinking about Environments
 
|
(cc: squeak-dev)
>> > I think the #1 thing I don't like about Environments is its viral >> > nature to force a change to the habits of the entire community, and >> > associated compatibility upheaval. >> >> Do environments actually require a change to existing code? Surely any >> existing code would simply load into a base environment and work exactly as >> now? > > Of course existing code would have to change if code it relies upon is > changed. For example, the Spur bootstrap does a lot of Monticello > scripting. If Monticello were moved into its own environment and the > classes there-in would lose their MC prefixes then the scripts in the Spur > bootstrap would have to change to match. The Monticello environment would > have to be imported and the class names changed. But that could all be done > automatically. I don't see it as a problem. > > As far as Chris's feelings, that's an argument for complete stasis. It > doesn't allow us to make any fundamental changes to the language for the > bnetter. t is precisely because environments allow code to be modularised > that we want it. It is precisely because people will have to modularise > their code that the habits of the entire community can, and should change. The audience I want to include into the Squeak community are not just developers but "users" too. Few systems besides Squeak have maintained enough restraint of features to still have that level of approachability. To a new user, Squeak can still say its a simple system of just objects sending messages and nothing more. It seems possible that Environments could interfere with that. It feels like a consequential solution to an inconsequential problem. For me, a "Squeak-style" solution to the requirements we've mentioned in this thread could be strictly met by the UI-level hack: Requirement #1 -- must be able to resolve a name-collision between systems, should it occur. We agreed that the Rewrite tool can be used to rename classes, as it could to resolve a name-collision. Requirement #2 -- must be able to see pretty names in the code, with an easy way to disambiguate. We could add a "show prefixes" check box to the CodeEditor menu. Checked shows the real code, unchecked renders the code with the prefixes removed. Requirment #3 -- must be able to type pretty names in the code, with an easy way to disambiguate them on save. Nothing to do. Squeak 4.5 already allows pretty names to be typed. If the user had "show prefixes" unchecked when they started editing the method, or otherwise typed a pretty name, the system today will prompt them for which, i.e., "Session" they meant. The replacment is done but then after the method is re-rendered according to the show-prefixes setting. -------- Does this not, in the strictest sense, meet the requirements? This level of functional leverage is what captured and maintained my love for Squeak. > I should say that our experience with VW was that we created a Smalltalk > namespace which imported all the base namespaces so that for programmers > that didn't reach into more exotic parts of the system there was no real > change. So everybody's habits don't have to change al at once. But > Smalltalk (the namespace) is crowded, two-letter prefixes are a hack, and > putting things in environments is a neat and comprehensible change. Why > now, when we have environments in the system, are objections being raised? The time when you created a Smalltalk namespace in VW was a different context. As a rising off-the-shelf commercial product with potentially closed or copyrighted code (even from 3rd party vendors), customers would not have the option to employ the Rewrite solution as we do. So a "ultimate solution" to allow any-or-all-code to coexist with no changes had to be built. An open-source, DIY-style system like Squeak does not bear this requirement. > Chris, what would you do? Rip them out? No. They're already there, so let's let them get tested out by someone. If you don't mind, I might add that "show prefixes" feature because I DO like reading and writing pretty names sometimes, like for teaching and demos, but I just don't see myself rewriting the entire "Ma" stack for it. |
Re: Thinking about Environments
|
|
Hi,
Am 19.12.2014 um 22:18 schrieb Chris Muller: snip.. > The audience I want to include into the Squeak community are not just > developers but "users" too. ...snip considering myself a Squeak user I theoretically see the benefits of environments, but assume I'll rarely need them. So yes, leave them in. Besides being helpful when using foreign libraries I too use some names only to avoid conflict with existing classes. Practically only this week on the newbies list two people have been bitten by the fact that environments broke project save and this hasn't been fixed. I remember other people stumbling over this before and I keep using 4.4 for development and only use 4.5 for deployment because I use projects for documentation. Craigs approach seems plausible too but it's not yet main Squeak. Cheers, Herbert |
Re: Thinking about Environments
|
|
On Fri, Dec 19, 2014 at 11:06:38PM +0100, Herbert K??nig wrote:
> Hi, > Am 19.12.2014 um 22:18 schrieb Chris Muller: > snip.. > >The audience I want to include into the Squeak community are not just > >developers but "users" too. > ...snip > considering myself a Squeak user I theoretically see the benefits of > environments, but assume I'll rarely need them. So yes, leave them in. +1 I don't know how much I will make use of Environments, but from everything that I have read and seen, this is a simple and intelligently designed approach to the problem. I also recall that it was enthusiastically supported by Andreas Raab, which to me is a very strong endorsement of the approach. My sense is that Environments is 98% done. We should make every effort to ensure that the last 2% gets finished, and that the Environments system is put to some good use. By that I a mean a working example of using it in some useful way, no matter how big or how small. > Besides being helpful when using foreign libraries I too use some names > only to avoid conflict with existing classes. > > Practically only this week on the newbies list two people have been > bitten by the fact that environments broke project save and this hasn't > been fixed. > I remember other people stumbling over this before and I keep using 4.4 > for development and only use 4.5 for deployment because I use projects > for documentation. I think you are exactly right. And IIUC, the issues with project save are related to a short list of issues that Levente has been identifying. Sorry I don't have a link right now, but Levente has been asking for help on this for quite a while. So we need to address the "Levente list" of issues and get Squeak back to the point where project saving works properly. >From my point of view, if we could do two things I would be happy: 1) Fix the "Levente list" and get project save working. I think that's the 2% that still needs to be done for Environments. 2) Use environments for something. Maybe just a hello world example to illustrate, or maybe something related to a real project. I don't care what it is, I'd just like to have a working example that I can look at for reference. Probably other people will point out that more tool support is needed, but personally I would be happy with just these two things. > > Craigs approach seems plausible too but it's not yet main Squeak. I think it is more than just plausible, it is potentially quite revolutionary. But is a different set of ideas than Environments, and I don't think that either one needs to exclude the other. Dave > > Cheers, > > Herbert |
Re: Thinking about Environments
|
|
> On Dec 19, 2014, at 6:50 PM, David T. Lewis <[hidden email]> wrote: > > On Fri, Dec 19, 2014 at 11:06:38PM +0100, Herbert K??nig wrote: >> Hi, >> Am 19.12.2014 um 22:18 schrieb Chris Muller: >> snip.. >>> The audience I want to include into the Squeak community are not just >>> developers but "users" too. >> ...snip >> considering myself a Squeak user I theoretically see the benefits of >> environments, but assume I'll rarely need them. So yes, leave them in. > > +1 > > I don't know how much I will make use of Environments, but from everything > that I have read and seen, this is a simple and intelligently designed > approach to the problem. I also recall that it was enthusiastically supported > by Andreas Raab, which to me is a very strong endorsement of the approach. > > My sense is that Environments is 98% done. We should make every effort to > ensure that the last 2% gets finished, and that the Environments system is > put to some good use. By that I a mean a working example of using it in > some useful way, no matter how big or how small. > >> Besides being helpful when using foreign libraries I too use some names >> only to avoid conflict with existing classes. >> >> Practically only this week on the newbies list two people have been >> bitten by the fact that environments broke project save and this hasn't >> been fixed. >> I remember other people stumbling over this before and I keep using 4.4 >> for development and only use 4.5 for deployment because I use projects >> for documentation. > > I think you are exactly right. And IIUC, the issues with project save are > related to a short list of issues that Levente has been identifying. Sorry > I don't have a link right now, but Levente has been asking for help on this > for quite a while. So we need to address the "Levente list" of issues and > get Squeak back to the point where project saving works properly. > >> From my point of view, if we could do two things I would be happy: > > 1) Fix the "Levente list" and get project save working. I think that's > the 2% that still needs to be done for Environments. > > 2) Use environments for something. Maybe just a hello world example to > illustrate, or maybe something related to a real project. I don't care > what it is, I'd just like to have a working example that I can look at > for reference. I think I’ll be able to offer a simple example sometime in January or February. It’ll be a simple versioning system, nothing more complicated than an Array of Environments. I’ll put different versions of SQSqueakApplication (the homepage) in individual Environments and store them in an Array. This would be an elemental versioning system. Replacing SQSqueakApplication with a variable, I could switch between the versions in the Array to decide which version Altitude serves to the web. With a control panel I could choose which one I want. With ALClient I could push source code to the server from my desktop to be compiled in different Environments. Using Altitude’s resource system, I could run all versions on different URIs to see them simultaneously in different tabs . Environments sound grand and sweeping, but I think I think the could have simpler uses. If I get this running, I’ll post it. Chris > > Probably other people will point out that more tool support is needed, > but personally I would be happy with just these two things. > >> >> Craigs approach seems plausible too but it's not yet main Squeak. > > I think it is more than just plausible, it is potentially quite revolutionary. > But is a different set of ideas than Environments, and I don't think that > either one needs to exclude the other. > > Dave > >> >> Cheers, >> >> Herbert > |
Re: Thinking about Environments
|
|
Let me try that last sentence again with a bit more editing. Environments sound grand and sweeping, but I think they could have simpler uses. If I get this running, I’ll post it.
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |