Environments
Locked
123
123
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
 
|
It's my personal computing environment that I use for experiments and enlightenment. What I love most (in order of priority): 1. Hitting the "update button" :-) 2. Writing a five-liner to do something Really Hard (tm). 3. Reading discussions on Squeak-dev. Cheers, - Andreas |
|
|
In reply to this post by Bert Freudenberg
On 6/27/12 6:29 AM, "Bert Freudenberg" <[hidden email]> wrote: > On 27.06.2012, at 10:35, Göran Krampe wrote: > >> Personally I am *happy* that this stone is finally turned. >> >> On the other hand I am *unhappy* that you aren't facing any opposition >> because unfortunately it may just indicate that our community have shrunk >> considerably and people are instead flaming each other over on Pharo-dev. ;) >> >> regards, Göran > > > It just means that Squeak is a happier and friendlier place now. > > Taking tension out of the community was the only good outcome of the fork. > > - Bert - > Los cementerios estan llenos de paz The cemeteries are full of peace Edgar |
|
|
In reply to this post by Göran Krampe
On 27 June 2012 09:35, Göran Krampe <[hidden email]> wrote:
> Hi Colin and all! > > First of all - you are brave :) > > Anyway, a few thoughts of mine, although I am no longer "invested" in this > area, I was earlier but have given up waaaay back. > > 1. AFAICT this will (in contrary to my solution) remove the "modelessness" > we have today. Or in other words, a code snippet will behave differently > depending on which environment you are in. One can argue that this also > holds true today (class variables shadowing globals for example) but still. > It reminds me of VA for Java where you had to tell the "Workspace" in which > class it was being run (in order to get all the imports right). I am not > sure I like where this is leading. NOTE: My proposal meant that all class > refs were actually in full, never short. They just "rendered" short when it > was reasonable. > > 2. Reading code will force me to always be aware of which environments are > imported into the package I am reading. Otherwise I will not know which > class is referred to when I read "Manager". NOTE: My proposal would always > expand names into full names if there were more than two in the image. Which means tools might need adjusting. Hover over a class name and the browser tells you the local name and, if it's an import, where it came from and what its "real" name is. (I'd love to have that kind of thing anyway, actually: in your Debugger, being able to hover over a variable to see its value would be marvelous. A topic for another day.) > 3. And finally, this is AFAICT the same "pessimistic" approach that Java etc > use - in other words, each developer/project will create his/her own little > sandbox (=environment) and will start creating duplicate names for things > (knowingly or unknowingly) and will never really "notice" this because this > solution will never make it apparent that it has been done. NOTE: My > proposal would lead to ambiguous names being rendered with full path and > also asking the developer if he meant Color::Orange of Fruit::Orange > whenever he tried to type just "Orange" - thus making him (and all others) > aware of the slightly unfortunate name clash. On the flip side it means I can safely compose two libraries that I'd really like to use together, but can't, because they use the same class names. And I can do that without rewriting source. More importantly, Environment is a wedge. First you can load multiple classes with the same name. Then you can hide classes, protecting a library's internals (Environment does this already). Then you can selectively import those external classes you need (Environment does this already). Then you can _only_ import external references, and not just rely on some ambient knows-everything environment. And hey, you're suddenly forced into declaring your library's dependencies. That is _good_. Controlling classes is the easy part, but one thing at a time. frank > I am merely contrasting this with my own proposal from years back in order > to hear people's views on the above aspects. > > Personally I am *happy* that this stone is finally turned. > > On the other hand I am *unhappy* that you aren't facing any opposition > because unfortunately it may just indicate that our community have shrunk > considerably and people are instead flaming each other over on Pharo-dev. ;) > > regards, Göran > |
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
|
|
In reply to this post by dcorking
On Wed, Jun 27, 2012 at 12:09:23PM +0100, David Corking wrote:
> A few minute ago , G?ran Krampe wrote: > > > These days I am unsure of Squeak's "place" in the world. > > To all: where is Squeak in your world? > I like spending time with Squeak, and I appreciate that it is different in ways that attract creative, intelligent people who don't necessarily pay attention to what other people think is the the latest cool thing. I spend a good deal of my personal free time with Squeak because I enjoy it, I learn from it, and I like being part of the community. Dave |
|
|
In reply to this post by Frank Shearar-3
Hey!
On 06/27/2012 03:46 PM, Frank Shearar wrote: > On 27 June 2012 09:35, Göran Krampe <[hidden email]> wrote: >> Hi Colin and all! >> >> First of all - you are brave :) >> >> Anyway, a few thoughts of mine, although I am no longer "invested" in this >> area, I was earlier but have given up waaaay back. >> >> 1. AFAICT this will (in contrary to my solution) remove the "modelessness" >> we have today. Or in other words, a code snippet will behave differently >> depending on which environment you are in. One can argue that this also >> holds true today (class variables shadowing globals for example) but still. >> It reminds me of VA for Java where you had to tell the "Workspace" in which >> class it was being run (in order to get all the imports right). I am not >> sure I like where this is leading. NOTE: My proposal meant that all class >> refs were actually in full, never short. They just "rendered" short when it >> was reasonable. >> >> 2. Reading code will force me to always be aware of which environments are >> imported into the package I am reading. Otherwise I will not know which >> class is referred to when I read "Manager". NOTE: My proposal would always >> expand names into full names if there were more than two in the image. > > Which means tools might need adjusting. Hover over a class name and > the browser tells you the local name and, if it's an import, where it > came from and what its "real" name is. > > (I'd love to have that kind of thing anyway, actually: in your > Debugger, being able to hover over a variable to see its value would > be marvelous. A topic for another day.) Agree on both accounts. Just trying to remind us that this will add a "mental hurdle" in reading code. Sure, tools can help - but only so much. >> 3. And finally, this is AFAICT the same "pessimistic" approach that Java etc >> use - in other words, each developer/project will create his/her own little >> sandbox (=environment) and will start creating duplicate names for things >> (knowingly or unknowingly) and will never really "notice" this because this >> solution will never make it apparent that it has been done. NOTE: My >> proposal would lead to ambiguous names being rendered with full path and >> also asking the developer if he meant Color::Orange of Fruit::Orange >> whenever he tried to type just "Orange" - thus making him (and all others) >> aware of the slightly unfortunate name clash. > > On the flip side it means I can safely compose two libraries that I'd > really like to use together, but can't, because they use the same > class names. And I can do that without rewriting source. In fact, my solution (sorry for referring to it - but I do it for "comparison", not trying to push it) allowed that too because *all* class references in source code were always *in full*. In other words - it worked just like prefixes does today. You can easily combine Seaside (WA*) with Monticello (MC*) and no names will clash. In essence, my solution was "prefixing improved", so it worked exactly the same. > More importantly, Environment is a wedge. First you can load multiple > classes with the same name. Then you can hide classes, protecting a > library's internals (Environment does this already). Then you can > selectively import those external classes you need (Environment does > this already). Then you can _only_ import external references, and not > just rely on some ambient knows-everything environment. And hey, > you're suddenly forced into declaring your library's dependencies. > That is _good_. Personally I just feel complexity lurking in the shadows... I hope I am wrong. ;) regards, Göran |
|
|
On 27 June 2012 15:54, Göran Krampe <[hidden email]> wrote:
> Hey! > > > On 06/27/2012 03:46 PM, Frank Shearar wrote: >> >> On 27 June 2012 09:35, Göran Krampe <[hidden email]> wrote: >>> >>> Hi Colin and all! >>> >>> First of all - you are brave :) >>> >>> Anyway, a few thoughts of mine, although I am no longer "invested" in >>> this >>> area, I was earlier but have given up waaaay back. >>> >>> 1. AFAICT this will (in contrary to my solution) remove the >>> "modelessness" >>> we have today. Or in other words, a code snippet will behave differently >>> depending on which environment you are in. One can argue that this also >>> holds true today (class variables shadowing globals for example) but >>> still. >>> It reminds me of VA for Java where you had to tell the "Workspace" in >>> which >>> class it was being run (in order to get all the imports right). I am not >>> sure I like where this is leading. NOTE: My proposal meant that all class >>> refs were actually in full, never short. They just "rendered" short when >>> it >>> was reasonable. >>> >>> 2. Reading code will force me to always be aware of which environments >>> are >>> imported into the package I am reading. Otherwise I will not know which >>> class is referred to when I read "Manager". NOTE: My proposal would >>> always >>> expand names into full names if there were more than two in the image. >> >> >> Which means tools might need adjusting. Hover over a class name and >> the browser tells you the local name and, if it's an import, where it >> came from and what its "real" name is. >> >> (I'd love to have that kind of thing anyway, actually: in your >> Debugger, being able to hover over a variable to see its value would >> be marvelous. A topic for another day.) > > > Agree on both accounts. Just trying to remind us that this will add a > "mental hurdle" in reading code. Sure, tools can help - but only so much. > > >>> 3. And finally, this is AFAICT the same "pessimistic" approach that Java >>> etc >>> use - in other words, each developer/project will create his/her own >>> little >>> sandbox (=environment) and will start creating duplicate names for things >>> (knowingly or unknowingly) and will never really "notice" this because >>> this >>> solution will never make it apparent that it has been done. NOTE: My >>> proposal would lead to ambiguous names being rendered with full path and >>> also asking the developer if he meant Color::Orange of Fruit::Orange >>> whenever he tried to type just "Orange" - thus making him (and all >>> others) >>> aware of the slightly unfortunate name clash. >> >> >> On the flip side it means I can safely compose two libraries that I'd >> really like to use together, but can't, because they use the same >> class names. And I can do that without rewriting source. > > > In fact, my solution (sorry for referring to it - but I do it for > "comparison", not trying to push it) allowed that too because *all* class > references in source code were always *in full*. > > In other words - it worked just like prefixes does today. You can easily > combine Seaside (WA*) with Monticello (MC*) and no names will clash. In > essence, my solution was "prefixing improved", so it worked exactly the > same. It's not really implicit. Given two libraries with "Session", you'd import and _locally_ prefix as MaSession and WaSession. When you read the code, you'd see those names, note the prefix, and possibly check the Environment import list. frank >> More importantly, Environment is a wedge. First you can load multiple >> classes with the same name. Then you can hide classes, protecting a >> library's internals (Environment does this already). Then you can >> selectively import those external classes you need (Environment does >> this already). Then you can _only_ import external references, and not >> just rely on some ambient knows-everything environment. And hey, >> you're suddenly forced into declaring your library's dependencies. >> That is _good_. > > > Personally I just feel complexity lurking in the shadows... I hope I am > wrong. ;) It's more that complexity is right in the room and everyone covers their eyes, puts their fingers in their ears and goes "lalalala" at the top of their voices. Modularity is hard. frank > regards, Göran > |
|
|
In reply to this post by Göran Krampe
Hi Göran,
On Wed, Jun 27, 2012 at 1:35 AM, Göran Krampe <[hidden email]> wrote:
1. AFAICT this will (in contrary to my solution) remove the "modelessness" we have today. Or in other words, a code snippet will behave differently depending on which environment you are in. One can argue that this also holds true today (class variables shadowing globals for example) but still. It reminds me of VA for Java where you had to tell the "Workspace" in which class it was being run (in order to get all the imports right). I am not sure I like where this is leading. NOTE: My proposal meant that all class refs were actually in full, never short. They just "rendered" short when it was reasonable. Yes, you're quite right. It's the main difference between this proposal and VW, GST, and Gemán's GSOC work. I think Gemstone might be the only similar implementation, although I'm not conversant with the subtleties of Gemstone.
To me, this is a feature, not a bug. By giving up the notion of a single, universal view of the system, we gain a degree of freedom that we didn't have before. If we write code that doesn't rely on knowing where to find the classes it depends on, we gain the ability to redefine those dependencies without altering the code. 2. Reading code will force me to always be aware of which environments are imported into the package I am reading. Otherwise I will not know which class is referred to when I read "Manager". NOTE: My proposal would always expand names into full names if there were more than two in the image. Also true. But you could say the same thing about dynamic dispatch: you always have to be aware the class of the receiver, otherwise you won't know what method will be executed. We mitigate message ambiguity with dev tools (implementors, explain) and we can do the same with class references. 3. And finally, this is AFAICT the same "pessimistic" approach that Java etc use - in other words, each developer/project will create his/her own little sandbox (=environment) and will start creating duplicate names for things (knowingly or unknowingly) and will never really "notice" this because this solution will never make it apparent that it has been done. NOTE: My proposal would lead to ambiguous names being rendered with full path and also asking the developer if he meant Color::Orange of Fruit::Orange whenever he tried to type just "Orange" - thus making him (and all others) aware of the slightly unfortunate name clash. In practice we tend to do this already. We just pick a prefix and rely on that to avoid name conflicts. And why not? We're long past the point where we can have a single, unmangled namespace for all the classes that might get loaded into a given image.
Thanks for the pushback, Göran. Insightful as always.
Colin
|
|
|
In reply to this post by David T. Lewis
I don't code my projects in squeak , because I don't really like smalltalk syntax as much I love python. But I do like to play around with squeak and pharo and copy all their cool ideas to python. Right now I am making a project that has the ambition to sort of (emphasis on "sort of") port squeak to python. I started with porting Morphic , to my GUI which I call Morpheas. Its not a copy from the code side , though there are still a lot of similarities , but more like a copy at the user side, of all the super cool functionally that we have come to love in Morphic and with several other enhancements that I plan for it. My project is named "Ephestos" and you can find it here -> https://github.com/kilon/Ephestos I have
announced it here , and even had a squeak source page for it because I first intended to make it for squeak, but it was also my intention to integrate it to Blender. Also I knew that multicore functionality and threads would be kinda cool , include to that the not so great squeak documentation, buggy libraries and lack of them, choosing python was the easy option of course once again Blender supporting python played a huger role to my decision too. But squeak is not completely out of the window as option. Part of my project is to provide a bridge between languages so it makes possible to use Ephestos with all languages. At the moment my bridge works cross blender python, cpython 3 , cpython 2 and pypy. But because its XMLRPC and sockets it should work relatively easily for squeak too. Using that bridge its possible with no extra magic to call directly all Ephestos (and even blender's) functions . My code is 100% pure python so its easy to read even for
those that don't know python at all. Of course there is tons of stuff we need to implement to Ephestos and is nowhere near to squeak at the moment. But at the good side, Blender users through Ephestos and Morpheas learn what Morphic is all about so you may have some more newcomers coming from my side and I would certainly recommend and support squeak, because its awesome. I have already introduced many people to it. I don't think squeak will ever die , its too cool for that, but even if it did, through projects like mine that are intended for other language will live forever, because a great idea is copied a million times and is never lost. I also agree the community of squeak and pharo is very nice, polite and helpful , probably the second best in my experience after the blender
community. From: David T. Lewis <[hidden email]> To: The general-purpose Squeak developers list <[hidden email]> Sent: Wednesday, 27 June 2012, 17:17 Subject: Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments) On Wed, Jun 27, 2012 at 12:09:23PM +0100, David Corking wrote: > A few minute ago , G?ran Krampe wrote: > > > These days I am unsure of Squeak's "place" in the world. > > To all: where is Squeak in your world? > I like spending time with Squeak, and I appreciate that it is different in ways that attract creative, intelligent people who don't necessarily pay attention to what other people think is the the latest cool thing. I spend a good deal of my personal free time with Squeak because I enjoy it, I learn from it, and I like being part of the community. Dave |
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
|
|
In reply to this post by Göran Krampe
On Wed, Jun 27, 2012 at 3:50 AM, Göran Krampe <[hidden email]> wrote:
I definitely agree with the friendly part. That is something I have always been proud of - the friendliness of our community. Well, there's no doubt that the community forked along with the code. There are a few people who contribute to both Pharo and Squeak, but not a lot. This leads to both communities being smaller, although you don't notice that with Pharo.
Earlier Seaside and web development has been a "driver" behind the community - the fact that if you build web apps, it doesn't matter how the backend "looks" (thus the UI of Squeak was of no importance). Well, I'm still using Squeak for web development. Sure, most of the web dev crowd has moved to Pharo, but Squeak is still a good platform for the web. These days I am unsure of Squeak's "place" in the world. On of the effects of the fork has been to reduce the pressure on us, in the Squeak community, to make releases with big new features or invasive "cleaning". That, in turn has allowed us to focus on fundamentals that aren't flashy, but are important to advancing the platform. A lot of our work in the past couple of years has been around forging better links with other forks of Squeak, oddly enough.
Along with VRPI, we did the legwork to make the MIT relicensing happen. We merged in code from the Cuis, Teleplace, and Etoys forks, both to improve Squeak and to make it more compatible with those variants. Recently we've been working on fixing compatibility issues with the Scratch fork so that it can continue to work even though the new version of Scratch will be based on Flash.
One of the effects of our continued collaboration with the Etoys community has been to strengthen our ties with the wider world of open source. Many Linux distributions now include Squeak packages. Randall has been giving talks about Squeak in more "mainstream" fora dedicated to Linux and Perl.
So what's Squeak's place in the world? I'm not sure either, to tell the truth. It's changing, and the Pharo fork has had a lot to do with that. But I like the direction we're taking and a look forward to seeing where we end up.
Colin |
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
|
|
In reply to this post by dcorking
Am 27.06.2012 13:09, schrieb David Corking:
> To all: where is Squeak in your world? David Squeak *is* important to me. it is in this order: 1- The environment I enjoy to work in. Part of it being Etoys-iness and Morphic. 2- The environment in which I develop the tools I need for my work (middleware, simulation, engineering). 3- Compared to Pharo: A stable and backwards compatible API protecting my (my customers) investment. many more ... - Herbert |
|
|
In reply to this post by Göran Krampe
> On the other hand I am *unhappy* that you aren't facing any opposition
> because unfortunately it may just indicate that our community have shrunk > considerably and people are instead flaming each other over on Pharo-dev. ;) It's probably premature to say the idea won't face any opposition. Right now I think we're still trying to understand Colins proposal before we flame it. :) It was only proposed just the other day and the thread is already > 20 posts from 9 unique posters in a community of very busy members so... ;) |
|
|
On Wed, Jun 27, 2012 at 02:21:03PM -0500, Chris Muller wrote:
> > On the other hand I am *unhappy* that you aren't facing any opposition > > because unfortunately it may just indicate that our community have shrunk > > considerably and people are instead flaming each other over on Pharo-dev. ;) > > It's probably premature to say the idea won't face any opposition. > Right now I think we're still trying to understand Colins proposal > before we flame it. :) It was only proposed just the other day and > the thread is already > 20 posts from 9 unique posters in a community > of very busy members so... ;) Well there's a fine kettle of fish for you. Someone attempts to light up a good flame war and it just degenerates into a slow stream of thoughtful commentary, constructive ideas, and high quality code contributions. What have we come to? ;) Dave |
|
|
> Well there's a fine kettle of fish for you. Someone attempts to light up
> a good flame war and it just degenerates into a slow stream of thoughtful > commentary, constructive ideas, and high quality code contributions. What > have we come to? You're all idiots anyway ! (is that a good start for a flame war ?) STef |
|
|
On Thu, Jun 28, 2012 at 12:39:15AM +0200, St?phane Rollandin wrote:
> >Well there's a fine kettle of fish for you. Someone attempts to light up > >a good flame war and it just degenerates into a slow stream of thoughtful > >commentary, constructive ideas, and high quality code contributions. What > >have we come to? > > You're all idiots anyway ! > > (is that a good start for a flame war ?) > Nice try, but we still like you and value your input ;) |
|
|
In reply to this post by Colin Putney-3
> (Environment name: 'Application') > importSmalltalk; > import: #Seaside aliases: {#Session -> #SeasideSession}; > import: #Magma aliases: {#Session -> #MagmaSession}; > fileIn: 'Application.st'. Enhancement proposal: how about making this aliasing automatic, happening when the 'ambiguous' class is imported to begin with? Eg when Magma is first imported (into its own environment), the system is smart enough to discover that there are two environments with a class named Session, and automatically creates an alias to both of them, by prefixing the environment name (Seaside and Magma, respectively) to the class name (SeasideSession, MagmaSession). All users of the Seaside and Magma environments now have access to disambiguated names 'for free', without having the responsability to manually maintain a list of name-clashes in the world outside themselves (ie in the packages they depend on). |
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
|
|
In reply to this post by Herbert König
Squeak's place in the world is as a platform for Aikido-style
development concerned with real-world domains that require longevity. The current trunk platform represents the product of ~15 years of discussions, arguments, wrangling and sweat from an incredibly talented and diverse group of developers. I believe this community recognizes the value of its approach. As the trunk advances incrementally, the community moves forward together as a unit. Everyone benefits by everyone else's work because work from the past is respected, not belittled. Squeak does not want to take over the world or be "hip". It's members are independent-minded and generally want to "get there" on their own and not told what to think. On Wed, Jun 27, 2012 at 12:23 PM, Herbert König <[hidden email]> wrote: > Am 27.06.2012 13:09, schrieb David Corking: > >> To all: where is Squeak in your world? David > > > Squeak *is* important to me. it is in this order: > > 1- The environment I enjoy to work in. Part of it being Etoys-iness and > Morphic. > > 2- The environment in which I develop the tools I need for my work > (middleware, simulation, engineering). > > 3- Compared to Pharo: A stable and backwards compatible API protecting my > (my customers) investment. > > many more ... > > - Herbert > |
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
|
|
> Squeak's place in the world is as a platform for Aikido-style
> development Interesting; could you elaborate on this metaphor ? (I'm studying Aikido myself :) Stef |
Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)
|
|
The idea of getting a lot out of a little. I'm not a student of it
(yet), but I'm intrigued by the aspect of Aikido that "directs" the energy of the opposer rather than head-on resistance. Obviously this requires less power, like "Moving 100 pounds with 4 ounces" of T'ai Chi. For Squeak the opposer are the challenges that faced, the directing represents incremental advancement. On Thu, Jun 28, 2012 at 3:14 PM, Stéphane Rollandin <[hidden email]> wrote: >> Squeak's place in the world is as a platform for Aikido-style >> development > > > Interesting; could you elaborate on this metaphor ? > (I'm studying Aikido myself :) > > Stef > |
|
|
In reply to this post by michal-list
On Thu, Jun 28, 2012 at 2:34 AM, Michal <[hidden email]> wrote:
> >> (Environment name: 'Application') >> importSmalltalk; >> import: #Seaside aliases: {#Session -> #SeasideSession}; >> import: #Magma aliases: {#Session -> #MagmaSession}; >> fileIn: 'Application.st'. > > Enhancement proposal: > > how about making this aliasing automatic, happening when the > 'ambiguous' class is imported to begin with? Eg when Magma is first > imported (into its own environment), the system is smart enough to > discover that there are two environments with a class named Session, > and automatically creates an alias to both of them, by prefixing the > environment name (Seaside and Magma, respectively) to the class name > (SeasideSession, MagmaSession). > > All users of the Seaside and Magma environments now have access to > disambiguated names 'for free', without having the responsability to > manually maintain a list of name-clashes in the world outside > themselves (ie in the packages they depend on). That's a great idea. There would have to be a way to turn it off and keep full control, but yeah, if we have a default policy for disambiguating that would be really useful. Thanks, Michal! Colin |
|
|
On Thu, Jun 28, 2012 at 7:00 PM, Colin Putney <[hidden email]> wrote:
> On Thu, Jun 28, 2012 at 2:34 AM, Michal <[hidden email]> wrote: >> >>> (Environment name: 'Application') >>> importSmalltalk; >>> import: #Seaside aliases: {#Session -> #SeasideSession}; >>> import: #Magma aliases: {#Session -> #MagmaSession}; >>> fileIn: 'Application.st'. >> >> Enhancement proposal: >> >> how about making this aliasing automatic, happening when the >> 'ambiguous' class is imported to begin with? Eg when Magma is first >> imported (into its own environment), the system is smart enough to >> discover that there are two environments with a class named Session, >> and automatically creates an alias to both of them, by prefixing the >> environment name (Seaside and Magma, respectively) to the class name >> (SeasideSession, MagmaSession). >> >> All users of the Seaside and Magma environments now have access to >> disambiguated names 'for free', without having the responsability to >> manually maintain a list of name-clashes in the world outside >> themselves (ie in the packages they depend on). > > That's a great idea. There would have to be a way to turn it off and > keep full control, but yeah, if we have a default policy for > disambiguating that would be really useful. Thanks, Michal! > > Colin > Well, maybe. If I understand this right, then when you alias a class, you refer to the alias in the code that is loaded later. If, however, a class was left unaliased originally (in an import) and was then referenced in the code depending on that import, but later a NEW environment import was introduced with the same class, then if the new importer automatically aliased both of these, the code wouldn't know which one to use. Which would be unfortunate. In your Seaside / Magma example, could you leave one Session just as Session, and have the other aliased? Maybe the auto-aliaser would need to detect that the new code references a dual-defined class, and asks which one it should use? in other words, 'partially' auto alias. -Another Chris |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |