Hi Göran.<br><br>This is probably going to be my last post on this issue because I want to spend more time actually coding stuff.<br><br><div><span class="gmail_quote">On 9/20/07, <b class="gmail_sendername">Göran Krampe</b>
<<a href="mailto:goran@krampe.se">goran@krampe.se</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi!<br><br>Highly annoying - I had written a long reply and then it went poof into
<br>bit heaven. Ok, one more go:</blockquote><div><br><br>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 :-) ].<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * I also assume that to resolve conflicts of the namespace names<br>> themselves,<br>> the tools need to give the namespace a completely new name (which changes<br>> the source code as it's filed in), and to do this you'd need input from
<br>> the<br>> user?<br><br>Yes, but I have a hard time seeing a solution to this without a registry.</blockquote><div><br><br>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.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> * Your proposal still involves the use of a global dictionary containing
<br>> all<br>> global variables and classes. In computer science we learn that the use of<br>> global variables should be minimised, and your proposal certainly doesn't<br>> help us in this regard.<br><br>
I disagree. I think this is just an implementation detail. If you can<br>improve it by making Namespace instances hold the Assocations instead of<br>using the trick I am using - then by all means - go ahead! It would be<br>
cleaner implementation wise. But Andreas Raab strongly advised me to not<br>take on that "world of hurt" and I believed him.</blockquote><div><br><br>If you made Namespace instances hold associations, you would have accidentally implemented hierarchical namespaces ;-).
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I'm not against your proposal, and it doesn't make the situation any worse
<br>> than the current situation except for the filing out issue.<br><br>Given what I wrote above regarding filing out - do you still think it is<br>an issue? And also - does any OTHER solution do it any better? I don't
<br>think so.</blockquote><div><br><br>Argh. This is blatent provocation. It's a shame I can't resist replying.<br><br>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.
<br></div></div><br>My solution is arguably better, in theory, in that it solves a wider range of problems at the expense of being more complex.<br><br>Regards,<br>Gulik.<br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">
http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>