My namespace proposal described in Yet Another Try
Locked
123
123
 
|
On Thu, 20 Sep 2007 01:16:50 -0700, Göran Krampe <[hidden email]> wrote:
> Yes, but I have a hard time seeing a solution to this without a registry. > One may argue that the risk of collision would be less in an hierarchical > solution, but I tend to think that it is a small price to pay for the > greater simplicity. Mmmmmm. Namespace hierarchies.... System.Runtime.Remoting.RemotingConfiguration |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Göran Krampe
Hi Göran.
This is probably going to be my last post on this issue because I want to spend more time actually coding stuff. On 9/20/07, Göran Krampe
<[hidden email]> wrote: Hi! No... I spent time analysing it, reading your wiki pages and thinking about the consequences. I just don't like 500-line emails hitting my inbox so I snipped it. I'm not sure how it is for other people, but I usually read the short, concise, to-the-point emails and skip over the 500-line monstrosities because often they're mostly verbage and take ages to read through [present company excepted :-) ]. > * I also assume that to resolve conflicts of the namespace names My solution solves this by making import lists refer to namespaces in packages which are referenced by UUIDs. I'll spare the details until I can give you something to play with.
If you made Namespace instances hold associations, you would have accidentally implemented hierarchical namespaces ;-). > I'm not against your proposal, and it doesn't make the situation any worse Argh. This is blatent provocation. It's a shame I can't resist replying. Having run out of good technical disapprovings, I can't say much other than your approach doesn't feel to me like an elegant engineering marvel (which I'm sure you'd agree) because you're trying to do something in small evolutionary increments rather than taking a grander vision and think of an architectural design that solves as many current and potential future problems as possible. That said, your approach is more likely than my approach to be adopted by the wider Squeak community exactly because of this. My solution is arguably better, in theory, in that it solves a wider range of problems at the expense of being more complex. Regards, Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Ramon Leon-5
> I just
> want the damned browser to hide the prefixes (aka manual namespaces) like it > formats the code, a simple aesthetic preference. The only trouble is the problem is still not totally solved; you can still have a conflict. Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff. How many possible two-letter prefixes are there; 26 squared is only 676 namespaces and you know they won't all be used anyway. Not nearly enough for a large community developing a large variety of frameworks and applications with the general-purpose tool. So I guess we'd could all start using larger prefixes to ensure we could grow to a very large community with Göran's approach. Tell you what, I'm gonna stay slick with my two-letter prefixes but Lukas, please rename all your Magritte classes to use a longer one, ok? Ha ha, seriously, I don't see it necessarily as a problem *for me* as long as the tools were *really good* at hiding and auto-prefixing-on-save. However, I dubious that the entire community would be able (let alone willing) to engage in this sort of "collaborative cooperation" when individual project work beckons. No one should really have to, honestly. Sorry Göran, I guess I'm starting to waffle right back to my original desired solution of three years ago: > auto class rename on importing This could potentially be THE simplest, and most fool-proof solution (other than Craig Latta's NAIAD, perhaps). Make this work and we don't seem to need anything else. And it's a solution that is in the dynamic, malleable spirit of Smalltalk as well. On 9/20/07, Ramon Leon <[hidden email]> wrote: > > > Any "real" namespaces solution will eventually be rejected because > > > it's not a small change and a vocal part of the community > > doesn't want > > > it, just wait, you'll see. > > > > And also - all people rejecting any "real" solution (although > > I tend to argue with that choice of word) - are not entirely > > wrong either. > > > > regards, Göran > > By *real* I mean other overly complicated hierarchtical package managing, > code securing, auto class rename on importing, whiz-bang solutions that 99% > of us don't really need (obviously since we don't have that now). I just > want the damned browser to hide the prefixes (aka manual namespaces) like it > formats the code, a simple aesthetic preference. Nice, simple, keeps > Smalltalk as is, one global namespace, no imports, no ambiguity, just a > smarter view and a change small enough, with so little object to, that it > might actually happen within my lifetime. As it stands, it's by far the > most pragmatic solution on the table. > > Ramon Leon > http://onsmalltalk.com > > > |
RE: My namespace proposal described in Yet Another Try
|
|
> The only trouble is the problem is still not totally solved;
> you can still have a conflict. > > Magritte and Magma already both very nearly use the same prefix, "MA" > and "Ma", respectively. It's hard for me to accept, after > all this discussion and effort and say Göran's finally makes > it into the base image, that I could very easily collide with > Magritte unless at least one of us renames a bunch of stuff. We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it. > How many possible two-letter prefixes are there; 26 squared is only > 676 namespaces and you know they won't all be used anyway. > Not nearly enough for a large community developing a large > variety of frameworks and applications with the general-purpose tool. Doesn't matter, see above. > So I guess we'd could all start using larger prefixes to > ensure we could grow to a very large community with Göran's > approach. Tell you what, I'm gonna stay slick with my > two-letter prefixes but Lukas, please rename all your > Magritte classes to use a longer one, ok? If you don't have to type them when working within the package, I doubt you'd care that much. > Ha ha, seriously, I don't see it necessarily as a problem > *for me* as long as the tools were *really good* at hiding > and auto-prefixing-on-save. However, I dubious that the > entire community would be able (let alone willing) to engage > in this sort of "collaborative cooperation" when individual > project work beckons. No one should really have to, honestly. But we already do, the tools just aren't smart enough to allow us to hide it. Göran's proposal just takes current practice, prefixing, and adds tool support to make it a much nicer solution. We'd get a lot more mileage out of prefixing with tool support. > > Sorry Göran, I guess I'm starting to waffle right back to my > original desired solution of three years ago: > > > auto class rename on importing > > This could potentially be THE simplest, and most fool-proof > solution (other than Craig Latta's NAIAD, perhaps). Make > this work and we don't seem to need anything else. And it's > a solution that is in the dynamic, malleable spirit of > Smalltalk as well. And such a big change that it isn't likely to be implemented, just talked about endlessly until everyone gives up and the status quo is maintained. The thing that makes his proposal so nice is that it's just a tiny change to make the status quo good enough to let us actually have a working solution while everyone argues endlessly about something fancier. I see three options that are likely 1. Do nothing (most likely) 2. Do very little, Göran's approach, formalize and add tool support to *current prefixing practice* (possible, but unlikely) 3. Do a huge change and add full namespaces and get rid of the big bad global SystemDictionary (when hell freezes over in this community) So, being annoyed by seeing and typing prefixes constantly, and also being pragmatic and wanting to see a solution get accepted by the community, 2 seems the only viable option. As cool as 3 might be, it just isn't going to happen. Maybe I'm wrong, but that's my impression. Ramon Leon http://onsmalltalk.com |
Re: My namespace proposal described in Yet Another Try
|
|
Well I have to admit, there seems to be no harm in doing Göran's
proposal. It's an incremental step forward that should buy us a LOT of time, probably as much as we'll ever need. Also, like he said, does not preclude migrating to any other namespace solutions in the future. That alone is enough to win my vote of support. On 9/20/07, Ramon Leon <[hidden email]> wrote: > > The only trouble is the problem is still not totally solved; > > you can still have a conflict. > > > > Magritte and Magma already both very nearly use the same prefix, "MA" > > and "Ma", respectively. It's hard for me to accept, after > > all this discussion and effort and say Göran's finally makes > > it into the base image, that I could very easily collide with > > Magritte unless at least one of us renames a bunch of stuff. > > We use two letter prefixes because we're forced to see them and type them > constantly, with Göran's proposal, it'd be much more common to use > Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd > resolve naturally when you just used the short class name. Granted this > doesn't help existing packages with short prefixes, but it'd help new code. > If it worked well, I'd sure take the time to rename my code to use it. > > > How many possible two-letter prefixes are there; 26 squared is only > > 676 namespaces and you know they won't all be used anyway. > > Not nearly enough for a large community developing a large > > variety of frameworks and applications with the general-purpose tool. > > Doesn't matter, see above. > > > So I guess we'd could all start using larger prefixes to > > ensure we could grow to a very large community with Göran's > > approach. Tell you what, I'm gonna stay slick with my > > two-letter prefixes but Lukas, please rename all your > > Magritte classes to use a longer one, ok? > > If you don't have to type them when working within the package, I doubt > you'd care that much. > > > Ha ha, seriously, I don't see it necessarily as a problem > > *for me* as long as the tools were *really good* at hiding > > and auto-prefixing-on-save. However, I dubious that the > > entire community would be able (let alone willing) to engage > > in this sort of "collaborative cooperation" when individual > > project work beckons. No one should really have to, honestly. > > But we already do, the tools just aren't smart enough to allow us to hide > it. Göran's proposal just takes current practice, prefixing, and adds tool > support to make it a much nicer solution. We'd get a lot more mileage out > of prefixing with tool support. > > > > > Sorry Göran, I guess I'm starting to waffle right back to my > > original desired solution of three years ago: > > > > > auto class rename on importing > > > > This could potentially be THE simplest, and most fool-proof > > solution (other than Craig Latta's NAIAD, perhaps). Make > > this work and we don't seem to need anything else. And it's > > a solution that is in the dynamic, malleable spirit of > > Smalltalk as well. > > And such a big change that it isn't likely to be implemented, just talked > about endlessly until everyone gives up and the status quo is maintained. > The thing that makes his proposal so nice is that it's just a tiny change to > make the status quo good enough to let us actually have a working solution > while everyone argues endlessly about something fancier. > > I see three options that are likely > > 1. Do nothing (most likely) > 2. Do very little, Göran's approach, formalize and add tool support to > *current prefixing practice* (possible, but unlikely) > 3. Do a huge change and add full namespaces and get rid of the big bad > global SystemDictionary (when hell freezes over in this community) > > So, being annoyed by seeing and typing prefixes constantly, and also being > pragmatic and wanting to see a solution get accepted by the community, 2 > seems the only viable option. As cool as 3 might be, it just isn't going to > happen. Maybe I'm wrong, but that's my impression. > > Ramon Leon > http://onsmalltalk.com > > > > |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Ramon Leon-5
On Sep 20, 2007, at 8:12 PM, Ramon Leon wrote: >> Magritte and Magma already both very nearly use the same prefix, "MA" >> and "Ma", respectively. It's hard for me to accept, after >> all this discussion and effort and say Göran's finally makes >> it into the base image, that I could very easily collide with >> Magritte unless at least one of us renames a bunch of stuff. > > We use two letter prefixes because we're forced to see them and > type them > constantly, with Göran's proposal, it'd be much more common to use > Magritte:: or Magma:: as the prefix since you wouldn't be typing > it, it'd > resolve naturally when you just used the short class name. Granted > this > doesn't help existing packages with short prefixes, but it'd help > new code. > If it worked well, I'd sure take the time to rename my code to use it. > Actually, you are not forced to use two letter prefixes - you can use ten letter prefixes if you like. But it would get tiresome to type those - unless you created export names. How's that? When you build a package, use long names. But create a subclass of SharedPool with short names for all your classes bound to your classes. So if I create the FlamingWicked package, I would create a FlamingWickedExports subclass of SharedPool with the short names of my classes as class variables and a class initialize method that initializes the elements. FlamingPoolExports>>initialize Foo := FlamingWickedFoo. Bar := FlamingWickedBar.... Users of my package just add FlamingPoolExports to the PoolDictionaries in the class definition. No tool support required. -Todd Blanchard |
Re: My namespace proposal described in Yet Another Try
|
|
On 21/09/2007, Todd Blanchard <[hidden email]> wrote:
> > On Sep 20, 2007, at 8:12 PM, Ramon Leon wrote: > > >> Magritte and Magma already both very nearly use the same prefix, "MA" > >> and "Ma", respectively. It's hard for me to accept, after > >> all this discussion and effort and say Göran's finally makes > >> it into the base image, that I could very easily collide with > >> Magritte unless at least one of us renames a bunch of stuff. > > > > We use two letter prefixes because we're forced to see them and > > type them > > constantly, with Göran's proposal, it'd be much more common to use > > Magritte:: or Magma:: as the prefix since you wouldn't be typing > > it, it'd > > resolve naturally when you just used the short class name. Granted > > this > > doesn't help existing packages with short prefixes, but it'd help > > new code. > > If it worked well, I'd sure take the time to rename my code to use it. > > > > Actually, you are not forced to use two letter prefixes - you can use > ten letter prefixes if you like. But it would get tiresome to type > those - unless you created export names. How's that? When you build > a package, use long names. But create a subclass of SharedPool with > short names for all your classes bound to your classes. So if I > create the FlamingWicked package, I would create a > FlamingWickedExports subclass of SharedPool with the short names of > my classes as class variables and a class initialize method that > initializes the elements. > > FlamingPoolExports>>initialize > Foo := FlamingWickedFoo. > Bar := FlamingWickedBar.... > > Users of my package just add FlamingPoolExports to the > PoolDictionaries in the class definition. > No tool support required. > > -Todd Blanchard > > > -- Best regards, Igor Stasenko AKA sig. |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Ramon Leon-5
>
packages from 1 and 2 to 3 , i will use 3 without doubts.
> And such a big change that it isn't likely to be implemented, just talked > about endlessly until everyone gives up and the status quo is maintained. > The thing that makes his proposal so nice is that it's just a tiny change to > make the status quo good enough to let us actually have a working solution > while everyone argues endlessly about something fancier. > > I see three options that are likely > > 1. Do nothing (most likely) > 2. Do very little, Göran's approach, formalize and add tool support to > *current prefixing practice* (possible, but unlikely) > 3. Do a huge change and add full namespaces and get rid of the big bad > global SystemDictionary (when hell freezes over in this community) > > So, being annoyed by seeing and typing prefixes constantly, and also being > pragmatic and wanting to see a solution get accepted by the community, 2 > seems the only viable option. As cool as 3 might be, it just isn't going to > happen. Maybe I'm wrong, but that's my impression. > And then, if someone really want to use new code then he will be forced to use 3, and so, all current arguments against it will simply step back before a desire to use it. :) P.S. And i really don't care, do i need to type extra characters for prefix or not. As i said before, usually number of user-land(non core) class references in code is barely beyond 3. So i see no big harm in typing prefix couple times in couple of places. Comparing to benefits of namespaces its a joke. -- Best regards, Igor Stasenko AKA sig. |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Michael van der Gulik-2
Hi!
> Hi Göran. > > This is probably going to be my last post on this issue because I want to > spend more time actually coding stuff. > > On 9/20/07, Göran Krampe <[hidden email]> wrote: >> >> Hi! >> >> Highly annoying - I had written a long reply and then it went poof into >> bit heaven. Ok, one more go: > > No... I spent time analysing it, reading your wiki pages and thinking > about > the consequences. You misunderstood me - I was explaining that my email client crashed and that I had to write it all once more. :) >> > * I also assume that to resolve conflicts of the namespace names >> > themselves, >> > the tools need to give the namespace a completely new name (which >> changes >> > the source code as it's filed in), and to do this you'd need input >> from >> > the >> > user? >> >> Yes, but I have a hard time seeing a solution to this without a >> registry. > > My solution solves this by making import lists refer to namespaces in > packages which are referenced by UUIDs. I'll spare the details until I can > give you something to play with. > >> > * Your proposal still involves the use of a global dictionary >> containing >> > all >> > global variables and classes. In computer science we learn that the >> use >> of >> > global variables should be minimised, and your proposal certainly >> doesn't >> > help us in this regard. >> >> I disagree. I think this is just an implementation detail. If you can >> improve it by making Namespace instances hold the Assocations instead of >> using the trick I am using - then by all means - go ahead! It would be >> cleaner implementation wise. But Andreas Raab strongly advised me to not >> take on that "world of hurt" and I believed him. > > If you made Namespace instances hold associations, you would have > accidentally implemented hierarchical namespaces ;-). > >> I'm not against your proposal, and it doesn't make the situation any >> worse >> > than the current situation except for the filing out issue. >> >> Given what I wrote above regarding filing out - do you still think it is >> an issue? And also - does any OTHER solution do it any better? I don't >> think so. > > Argh. This is blatent provocation. It's a shame I can't resist replying. I meant "does any OTHER solution handle fileouts/filein in regards to compatibility any better"? Finally, let me assure you that I too *wonder* about what would be the best path forward. I am not totally convinced my proposal is IT - but I do defend it technically when details about it is discussed. For example, yesterday I played around with namespace renaming - with or without touching existing source - and got it almost working in both ways. And doing this I started wondering about the message passing style etc and if a solution based SOLELY on that would be better etc. - similar to Dan's original idea - but possibly WITHOUT the scoping rules etc. To be blunt, do it like Keith described more or less, instead of writing: Fruits::Orange ...we would write: Fruits Orange ...or: Namespace Fruits Orange ...or if we start fiddling with compiling a global ref to a send to thisContext, the above two would decompiled be: thisContext Fruits Orange ...and: thisContext Namespace Fruits Orange ...anyway, the whole idea being getting rid of all statically compiled global references and solely depend on dynamic lookup. A cool side effect of the thisContext trick (if at all feasible) would be backwards compatibility... perhaps. Enough rambling. :) regards, Göran |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Ramon Leon-5
On Sep 20, 2007, at 9:12 PM, Ramon Leon wrote: >> >> Magritte and Magma already both very nearly use the same prefix, "MA" >> and "Ma", respectively. It's hard for me to accept, after >> all this discussion and effort and say Göran's finally makes >> it into the base image, that I could very easily collide with >> Magritte unless at least one of us renames a bunch of stuff. > > We use two letter prefixes because we're forced to see them and > type them > constantly, with Göran's proposal, it'd be much more common to use > Magritte:: or Magma:: as the prefix since you wouldn't be typing > it, it'd > resolve naturally when you just used the short class name. Granted > this > doesn't help existing packages with short prefixes, but it'd help > new code. > If it worked well, I'd sure take the time to rename my code to use it. I completely agree with this as well - I would have no problem adding longer prefixes to my code, and would make class names more readable when they weren't shortened by the tools... - Brian |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Chris Muller-3
"Chris Muller" <[hidden email]> writes:
> Well I have to admit, there seems to be no harm in doing Göran's > proposal. It's an incremental step forward that should buy us a LOT > of time, probably as much as we'll ever need. Also, like he said, > does not preclude migrating to any other namespace solutions in the > future. That is an important consideration. If it is truly incremental, then that is a really nice property. However, is it really? How will we migrate forward to a hierarchical system where Array is at Collections::Core::Array instead of at Collections::Array ? There will already be code everywhere using Collections::Array . This all sounds very hasty to me. Instead of endlessly evaluating a quick and dirty scheme, how about the enthusiasts get together and make a system where: 1. Baby code in a starter image can mostly ignore namespaces. 2. A full hierarchy is available, not just one level. 3. Import lists are localized. 4. The source code does not need automatic rewriting in order to look nice. This is a doable list of properties, and I believe it could be solved faster than trying to convince everybody to use something incomplete. For bonus points, don't forget to check on the existing systems like GST's and VisualWork's, and don't forget to poll the major producers of Squeak code about what they want. Lex |
RE: My namespace proposal described in Yet Another Try
|
|
> That is an important consideration. If it is truly
> incremental, then that is a really nice property. > > However, is it really? How will we migrate forward to a > hierarchical system where Array is at > Collections::Core::Array instead of at Collections::Array ? > There will already be code everywhere using Collections::Array . He's not saying everything in the image needs to be converted to this, all the core classes can stay as they are now, global. The :: will mostly enable *new* code or code you choose to rename to use browser aware prefixes that can be hidden. > This all sounds very hasty to me. Instead of endlessly > evaluating a quick and dirty scheme, People have been trying to get some form on namespaces in Squeak for several years now. Gorans proposal is quite old, how exactly is that hasty? > how about the > enthusiasts get together and make a system where: > > 1. Baby code in a starter image can mostly ignore namespaces. > 2. A full hierarchy is available, not just one level. > 3. Import lists are localized. > 4. The source code does not need automatic rewriting > in order to look nice. > > This is a doable list of properties, and I believe it could > be solved faster than trying to convince everybody to use > something incomplete. > > For bonus points, don't forget to check on the existing > systems like GST's and VisualWork's, and don't forget to poll > the major producers of Squeak code about what they want. > > Lex Seriously, if we can't even agree to formalize some minimal tool support for the *existing practice* of prefixing, I can't see that anything else will ever get done. How many times does the attempt have to fail before everyone sees that these big sweeping hierarchtical/import solutions won't be accepted? Are namespaces in Squeak are just doomed to endless debate resulting in doing nothing over and over again and while we're all stuck with manual prefixes or non-standard add in packages forever? Ramon Leon http://onsmalltalk.com |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Michael van der Gulik-2
On 9/20/07, Michael van der Gulik <[hidden email]> wrote:
> > * It's a one-way street to adopt your proposal. Exactly. I haven't seen any evidence that we have the resources to put something in, decide it's bad and take it out again. I mean, traits is only beginning to be evaluated at all. |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Chris Muller-3
On 9/21/07, Chris Muller <[hidden email]> wrote:
> Well I have to admit, there seems to be no harm in doing Göran's > proposal. It's an incremental step forward that should buy us a LOT > of time, probably as much as we'll ever need. Also, like he said, > does not preclude migrating to any other namespace solutions in the > future. But it can be harm. Not to pick on traits, but to take it as an example. Have they helped? Andreas at least doesn't think so, and we still haven't seen conclusive evidence that they are going to help as implemented. If they turn out to be a bad idea how are they going to get ripped out again? And that's something that isn't even getting used that much. The namespaces will probably be used very quickly. I'm surprised there are no packages that depend on them already. |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Ramon Leon-5
On 9/21/07, Ramon Leon <[hidden email]> wrote:
> > We use two letter prefixes because we're forced to see them and type them > constantly, with Göran's proposal, it'd be much more common to use > Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd > resolve naturally when you just used the short class name. Granted this > doesn't help existing packages with short prefixes, but it'd help new code. > If it worked well, I'd sure take the time to rename my code to use it. I have a question: What is stopping you from using them right now today? Most of what you write is for private use, no? If so you can use namespaces until your hearts content. You could even make scripts to change Magritte and co to switch to the namespaces when loaded into your image, so that you don't have to type the prefixes anymore. Why do you need this to be in the default image to use it for private code? |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Göran Krampe
On 9/21/07, Göran Krampe <[hidden email]> wrote:
> > For example, yesterday I played around with namespace renaming - with or > without touching existing source - and got it almost working in both ways. > And doing this I started wondering about the message passing style etc and > if a solution based SOLELY on that would be better etc. - similar to Dan's > original idea - but possibly WITHOUT the scoping rules etc. > > To be blunt, do it like Keith described more or less, instead of writing: > > Fruits::Orange > > ...we would write: > > Fruits Orange > > ...or: > > Namespace Fruits Orange Now your coming to the good side! :) |
Re: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Göran Krampe
On 9/19/07, Göran Krampe <[hidden email]> wrote:
> Hi folks! > > - It is not hierarchical! It is simple "a bunch of named buckets". That's a hierarchy. Being hierarchical is not about how many levels, it's about the nature of the relationship: is it horizontal (relational) or vertical (hierarchical). I would say "a global space with a bunch of named buckets" is clearly vertical. > Please let this sink in. This means we have NO IMPORTS and we still don't > need to write or read qualified names! How is this done? Well, I have to admit, this part of your proposal has it's appeal. If you switched to a message passing syntax as mentioned before, then you'd get my little vote. > The trick is to let the source use fully qualified names at ALL TIMES and > just hook into the source code pane rendering code and the source code > editing code and make sure the tools "render" short names and accept short > names when being typed. Aha! So the trick is in the tools. The actual > source code is JUST LIKE BEFORE. And that is why my proposal is so darn > backwards compatible. <snip> > The snippet will bind and behave very differently based on where I run it. > Which class? What imports does it have? What does OrderedCollection > actually bind to? And how does a Workspace work? And what imports does the > debugger have and the inspectors and all other text panes? Please consider > this. So a solution that imports will make the code "magical" and unreadable, but why can the tools save us in your case, but not in that case? They can of course. The classes could be some kind of off color in the source code if they are non-global, with a pop up showing exactly where the class was taken from. A lot of options are possible for *both* types of solutions, we don't have to over simplify. |
RE: My namespace proposal described in Yet Another Try
|
|
In reply to this post by Jason Johnson-5
> I have a question: What is stopping you from using them
> right now today? Most of what you write is for private use, > no? If so you can use namespaces until your hearts content. > You could even make scripts to change Magritte and co to > switch to the namespaces when loaded into your image, so that > you don't have to type the prefixes anymore. > > Why do you need this to be in the default image to use it for > private code? > The same thing that stop me from wanting to over customize any environment, it makes all your code non standard, harder to share, harder to blog about, setting up new images becomes more work, all because no one wants to install something like Namespaces to just try it out. Namespaces belong in the core, not as an add on package. Why? For the same reason objects belong in the core and not as an add on package, look at Scheme's situation with objects, add on packages just get you *many* incompatible implementations of something where everyone argues endlessly about which to use. It's shameful to be forced to manually prefix our class names in what *professes* the be the ultimate object oriented language because every time the issue comes up people come out of the wood works to filibuster every attempt at a solution. I'm behind Gorans proposal because it's the smallest change possible that seems to make just a tiny bit of progress on an otherwise insurmountable mountain of an issue. Every other proposal is a pie in the sky fantasy not on technical merit, but on the social reality of this community. Gorans proposal is the only one that recognizes the *reality* that a big change just isn't going to happen, no matter how technically brilliant it might be. Ramon Leon http://onsmalltalk.com |
Re: My namespace proposal described in Yet Another Try
|
|
Traits got in.
On 10/4/07, Ramon Leon <[hidden email]> wrote: > > I have a question: What is stopping you from using them > > right now today? Most of what you write is for private use, > > no? If so you can use namespaces until your hearts content. > > You could even make scripts to change Magritte and co to > > switch to the namespaces when loaded into your image, so that > > you don't have to type the prefixes anymore. > > > > Why do you need this to be in the default image to use it for > > private code? > > > > The same thing that stop me from wanting to over customize any environment, > it makes all your code non standard, harder to share, harder to blog about, > setting up new images becomes more work, all because no one wants to install > something like Namespaces to just try it out. > > Namespaces belong in the core, not as an add on package. Why? For the same > reason objects belong in the core and not as an add on package, look at > Scheme's situation with objects, add on packages just get you *many* > incompatible implementations of something where everyone argues endlessly > about which to use. > > It's shameful to be forced to manually prefix our class names in what > *professes* the be the ultimate object oriented language because every time > the issue comes up people come out of the wood works to filibuster every > attempt at a solution. > > I'm behind Gorans proposal because it's the smallest change possible that > seems to make just a tiny bit of progress on an otherwise insurmountable > mountain of an issue. Every other proposal is a pie in the sky fantasy not > on technical merit, but on the social reality of this community. Gorans > proposal is the only one that recognizes the *reality* that a big change > just isn't going to happen, no matter how technically brilliant it might be. > > Ramon Leon > http://onsmalltalk.com > > > |
RE: My namespace proposal described in Yet Another Try
|
|
>
> Traits got in. That they did, but were there any alternative implementations to argue over? Traits seems to be the exception rather than the rule. You are right about something though, if Gorans proposal works well, I should be happy loading the packing and just using it. The problem is, there's more than one package using custom parsers, like the RefactoringBrowser and Shout that I rely on that aren't likely to be fixed unless they have to be, which is why I want something in the main image. Otherwise I'm stuck begging for patches they have no reason to actually support, or trying to fix things myself. If something's put in the core, everyone has to support it. Like I said previously, I don't actually think anyone's approach will be accepted. I fully expect the status quo to be maintained, I'm just hopeful that eventually, something will get done. Ramon Leon http://onsmalltalk.com |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |