Hi!
Göran Krampe wrote:
I agree with the "on its own merits" of course. The point of noticing Croquet "diversions" from regular Squeak is to get people to see that we (as in all Squeakers - forks like Croquet included) are indeed already changing things making various forks incompatible with each other.
It is extremely irritating to see these references to Croquet, traits, pragmas etc. which have nothing whatsoever to do with your proposed solution. So maybe you should stick to the benefits of your solution instead of making references to completely unrelated projects?
Mmmm, we are using them as examples of changes to the syntax and language - which they clearly are - and which this clearly is too. There is nothing wrong in doing that. If that annoys you, too bad. ;)
I clearly recall this positional thing popping up in another thread when someone was trying to get something from Croquet working in regular Squeak (my memory sucks).
Yes, in the OpenGL package. Which is (not coincidentally) the sole reason why we added it to begin with. Because, if you're a 3D guy you know OpenGL. And OpenGL has a *lot* of documentation that we could leverage by making it possible to transcribe C-code from:
glBegin(GL_QUADS); glVertex3f(0.0, 0.0, 0.0); glVertex3f(1.0, 0.0, 0.0); glVertex3f(1.0, 1.0, 0.0); glVertex3f(0.0, 1.0, 0.0); glEnd();
literally into:
ogl glBegin(GLQuads); glVertex3f(0.0, 0.0, 0.0); glVertex3f(1.0, 0.0, 0.0); glVertex3f(1.0, 1.0, 0.0); glVertex3f(0.0, 1.0, 0.0); glEnd(); yourself.
In other words you can copy and paste large portions of OpenGL code literally into Croquet and I think that was completely worth it.
I probably agree and have never said it wasn't worth it.
The nice thing about forks is that you can look at them, try them out, and then, with 20/20 hindsight can say whether a change like it makes sense for Squeak in general or not. But I don't think even you have used your namespace solution anywhere.
No, I haven't. I will though, but I don't think it will buy much more insight than possibly flushing out a few bugs and add a feature or two. It doesn't really say much about the larger picture.
You may be surprised about that. Speaking from my own experience just being able to use a fundamental feature like this in your daily work changes how you look at it. Because *wherever* you go you have the option to use it and when you had that chance for a couple of months and look back and say "so why did I use it here and not there and what would need to be true for me to use it there" is *extremely* helpful for understanding your own implicit motivations and what you expect from the solution you originally designed.
Yes, might be so - ask me in a year or so.
If there is any other claim you refer to - please specify.
No, it's just those - does that solution actually buy you anything in the long term, how do you use it in daily work, does rewriting your source code get annoying etc.
Ok, gotcha.
I am explaining and defending my solution, but I have generally given up on getting it accepted - it is just the same story all over again. So you don't have to worry. :)
The funny thing is that like I said initially I don't even care all that much but for some reason you get totally defensive about these issues.
Mmmm, perhaps I do - I apologize for that. I have tried not to :).
And there are things I simply won't let slip by like factual errors about what is and what is not true in the current system. If you want to advocate your solution, go for it, just don't do it based on provenly false claims (like "you can already use colons in class names so we must support this in global references" which will make me respond every single time).
I should have written that "you can already *create* classes with colons in their class names" - which is true no matter the reason. And AFAIK I did write that it probably was a bug, right? And I did take it back as an actual *argument* - which it was not really meant to be, I was more trying to indicate that things aren't that well defined as some may think.
regards, Göran