"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Anthony Hannan" ajh18@cornell.edu
but he also changed Class>>declare: to no longer raise a notifier when filing-in a class var that shadows another var.
Defining a class variable that shadows another var is neither an error nor something that needs to be debugged, so I don't see the reason for sending self error:, *at all*.
I would still like to see a notifier because I don't think it is not good style to shadow a global var. You can just change error: to notify:.
Also consider that if I install a program with 273 class variables that each have a reasonable chance of shadowing an existing global (or a pool variable, for that matter), I should not be required to press 'proceed' hundreds of times to install it. Or am I missing something?
I would enhance the notifier mechanism to allow "proceed for all".
Cheers, Anthony
From: "Anthony Hannan" ajh18@cornell.edu
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Anthony Hannan" ajh18@cornell.edu
but he also changed Class>>declare: to no longer raise a notifier when filing-in a class var that shadows another var.
Defining a class variable that shadows another var is neither an error
nor
something that needs to be debugged, so I don't see the reason for
sending
self error:, *at all*.
I would still like to see a notifier because I don't think it is good style to shadow a global var.
Anthony,
I'm going to try to convince you to think differently by asking a few questions:
1) Why do you think that it isn't good style to shadow a global var?
2) Do you think it is bad style to shadow a global variable by defining a class variable with the same name as an existing global?
3) Do you think it is bad style to define a global (class or otherwise) with the same name as an existing class variable?
4) If your answer on question 2) is 'yes', and your answer on question 3) is different, why the difference?
5) If your answer to both question 2) and 3) is 'yes', would you want a notifier in the scenario of 3) as well?
6) If your answer to the previous question is 'no', why not?
7) If your answer to question 5) is 'yes', how would the 'proceed all' functionality work?
BTW, I'm extremely interested in your project for a Smalltalk VM written in Smalltalk. Is there any code and/or a paper available?
Cheers,
Peter van Rooijen Amsterdam
You can just change error: to notify:.
Also consider that if I install a program with 273 class variables that
each
have a reasonable chance of shadowing an existing global (or a pool variable, for that matter), I should not be required to press 'proceed' hundreds of times to install it. Or am I missing something?
I would enhance the notifier mechanism to allow "proceed for all".
Cheers, Anthony
Anthony Hannan ajh18@cornell.edu wrote:
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Anthony Hannan" ajh18@cornell.edu
but he also changed Class>>declare: to no longer raise a notifier when filing-in a class var that shadows another var.
Defining a class variable that shadows another var is neither an error nor something that needs to be debugged, so I don't see the reason for sending self error:, *at all*.
I would still like to see a notifier because I don't think it is not good style to shadow a global var.
I'd go further; not only is it not good style, it is decidedly dangerous to the understandability of the system. Worse yet it makes a possibility that two bits of code that look very similar can refer to quite different variables. Even worse, the time-order of compiling methods could result in some refering to the global and some to the classvariable.
All in all, a terribly bad thing.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- If she was any dumber, she'd be a green plant.
From: "Tim Rowledge" tim@sumeru.stanford.edu
Anthony Hannan ajh18@cornell.edu wrote:
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Anthony Hannan" ajh18@cornell.edu
but he also changed Class>>declare: to no longer raise a notifier when filing-in a class var that shadows another var.
Defining a class variable that shadows another var is neither an error
nor
something that needs to be debugged, so I don't see the reason for
sending
self error:, *at all*.
I would still like to see a notifier because I don't think it is not good style to shadow a global var.
I'd go further; not only is it not good style, it is decidedly dangerous to the understandability of the system.
What exactly do you mean by "it", which you consider so dangerous?
Is it the fact that class variables shadow pool variables shadow global variables (i.e., part of the Smalltalk shared variable scope rules)? Or is it the fact that I am trying to bring Squeak in line with the Smalltalk shared variable scope rules?
Or is it perhaps something else?
Worse yet it makes a possibility that two bits of code that look very similar can refer to quite different variables.
That is indeed how Smalltalk works, yes.
Even worse, the time-order of compiling methods could result in some refering to the global and some to the classvariable.
No, it can't, unless there are bugs in the implementation (which currently probably do exist because it seems that this has not been given attention before). The scope rules are unambiguous. So, what you are saying is not a complaint against the scope rules.
All in all, a terribly bad thing.
In your view, is it so terribly bad that you would also want to prohibit people from defining globals with the same name as an existing class variable or pool variable?
Cheers,
Peter van Rooijen Amsterdam
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- If she was any dumber, she'd be a green plant.
"Peter van Rooijen" squeak@vanrooijen.com wrote:
What exactly do you mean by "it", which you consider so dangerous?
Is it the fact that class variables shadow pool variables shadow global variables (i.e., part of the Smalltalk shared variable scope rules)?
Yes. I think it's a really stupid thing to do. It doesn't matter if it is technically within any 'standard rules'. It's just plain dumb t do it.
Worse yet it makes a possibility that two bits of code that look very similar can refer to quite different variables.
That is indeed how Smalltalk works, yes.
You don't need to lecture me on how Smalltalk works. I've been making it professionally for twenty years.
Even worse, the time-order of compiling methods could result in some refering to the global and some to the classvariable.
No, it can't, unless there are bugs in the implementation (which currently probably do exist because it seems that this has not been given attention before). The scope rules are unambiguous. So, what you are saying is not a complaint against the scope rules.
Compile a method referring to a Foo global. Add a class variable Foo to the same class. (Squeak objects to this, I'm happy to see.) Compile another method referring to 'Foo'.
What do you expect to be the result?
All in all, a terribly bad thing.
In your view, is it so terribly bad that you would also want to prohibit people from defining globals with the same name as an existing class variable or pool variable?
Until and unless there is a clearly visible way to differentiate them, yes I would like to prevent it.
Consider another situation:- Class A has a method referring to Foo, a global. Class B, a subclass of A, adds a class variable Foo. A method in B refers to Foo, which clearly you claim binds to the class variable. It also sends a message which resolves to the method in A which refers to Foo the global.
Now try to make any internal sense of this when you have to debug or refactor this code. Yes, I'm sure that a compiler can be made to cope with it but our brains are not compilers (and I don't care what the Forth guys claim) and I feel pretty sure such code would present a major cognitive clash.
I don't care a fig what any standard says, it's foolish.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Disc space, the final frontier!
From: "Tim Rowledge" tim@sumeru.stanford.edu
"Peter van Rooijen" squeak@vanrooijen.com wrote:
What exactly do you mean by "it", which you consider so dangerous?
Is it the fact that class variables shadow pool variables shadow global variables (i.e., part of the Smalltalk shared variable scope rules)?
Yes. I think it's a really stupid thing to do. It doesn't matter if it is technically within any 'standard rules'. It's just plain dumb t do it.
Tim, let me get this straight: Before you define or rename a class you always check if any existing class has a class variable, or any existing pool dictionary has a pool variable with the name you are planning to use for your class. Correct? If the name is already in use in any of those places, you either change it there, or choose another name for your class. Right? After all, you wouldn't do a thing that is 'plain dumb to do'.
Worse yet it makes a possibility that two bits of code that look very similar can refer to quite different variables.
That is indeed how Smalltalk works, yes.
You don't need to lecture me on how Smalltalk works. I've been making it professionally for twenty years.
You are correct, I don't need to lecture you on how Smalltalk works. It also goes without saying that since you have been 'making it professionally for twenty years', your judgments about it are much more valuable than whatever opinion I might have about it.
Even worse, the time-order of compiling methods could result in some refering to the global and some to the classvariable.
No, it can't, unless there are bugs in the implementation (which
currently
probably do exist because it seems that this has not been given
attention
before). The scope rules are unambiguous. So, what you are saying is not
a
complaint against the scope rules.
Compile a method referring to a Foo global. Add a class variable Foo to the same class. (Squeak objects to this, I'm happy to see.) Compile another method referring to 'Foo'.
What do you expect to be the result?
I'm not sure I see what you're getting at, since this does not support your case at all. If both methods are in the same class, both occurrences of Foo refer to the class variable. What is your point?
All in all, a terribly bad thing.
In your view, is it so terribly bad that you would also want to prohibit people from defining globals with the same name as an existing class variable or pool variable?
Until and unless there is a clearly visible way to differentiate them, yes I would like to prevent it.
Should we be expecting a proposed enhancement from you for this?
Consider another situation:- Class A has a method referring to Foo, a global. Class B, a subclass of A, adds a class variable Foo. A method in B refers to Foo, which clearly you claim binds to the class variable. It also sends a message which resolves to the method in A which refers to Foo the global.
Now try to make any internal sense of this when you have to debug or refactor this code. Yes, I'm sure that a compiler can be made to cope with it but our brains are not compilers (and I don't care what the Forth guys claim) and I feel pretty sure such code would present a major cognitive clash.
Tim, I understand your example and I don't disagree that there is a potential for confusion. But this is just how Smalltalk is constructed. Classes are namespaces for their descendents. That Squeak hasn't correctly implemented this part of what Smalltalk is, does nothing to change this.
If you don't want to have to keep track of shared variable shadowing, try not to use duplicate names in your own code. You can't prevent shadowing from happening, since you don't control what globals someone else may define, but at least you can try and avoid adding to your own confusion.
But would you really have others prevented from using a legitimate, well-defined, Smalltalk construct, because you fear 'a major cognitive clash', because 'our brains are not compilers'?
I don't care a fig what any standard says, it's foolish.
Apparently, you would.
In any case, I have not become aware of any major cognitive clash in the user communities of any of the Smalltalk dialects that do implement shared variable shadowing correctly.
Perhaps someone with more than 20 years of professionally making Smalltalk can shine their light on the issue?
Cheers,
Peter van Rooijen Amsterdam
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Disc space, the final frontier!
Tim, let me get this straight: Before you define or rename a class you always check if any existing class has a class variable, or any existing pool dictionary has a pool variable with the name you are planning to use for your class. Correct?
Not quite; first, if I were able to actually live up to every piece of good practise that I know of or have attempted to teach then you'd be able to read by the glow of my halo :-)
Secondly, I think you've read a little more globalness into my words than I intended. Worrying about class variables in a disjoint hierarchy (and yes, one could point out that when all classes descend from Object that that is a dodgy concept) is probably going too far. PoolDicts are such a pain that I get a headache even saying the word let alone thinking about them. But basically, yes I try to make sure that there is minimal cognitive clash in the code. Do I fail? Oh boy, bigtime. Won't stop my trying and hoping that I can persuade others.
You are correct, I don't need to lecture you on how Smalltalk works. It also goes without saying that since you have been 'making it professionally for twenty years', your judgments about it are much more valuable than whatever opinion I might have about it.
Excessive humility is at least as big a sin as excessive pride. Say three Hail Alans and write out the morphic hierarchy 100 times in expiation.
Even worse, the time-order of compiling
[snip]
I'm not sure I see what you're getting at, since this does not support your case at all. If both methods are in the same class, both occurrences of Foo refer to the class variable. What is your point?
If the adding of the class variable results in the method that referred to the global Foo being changed 'under the covers' then the original intent of the writer has been subverted. If the original method is not changed then the association placed in the literal frame _looks_ like it refers to the class var - same textual name for the key - but is a quite different object to the association referred to by the other method.
This isn't something I worry about enough to be motivated to debate to death let alone to actually write code for. I have _way_ too many other things to handle. I've had my little rant and that's sufficient for now. Any time I catch code commiting this little sin I'll complain and hope to persuade someone to accept a change.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PRM: PRint Money
From: "Tim Rowledge" tim@sumeru.stanford.edu [snip]
You are correct, I don't need to lecture you on how Smalltalk works. It
also
goes without saying that since you have been 'making it professionally
for
twenty years', your judgments about it are much more valuable than
whatever
opinion I might have about it.
Excessive humility is at least as big a sin as excessive pride. Say three Hail Alans and write out the morphic hierarchy 100 times in expiation.
Tim, I have no problem with you, or anyone else, displaying arrogance. In fact, in most instances, I will enjoy it.
At the same time, there is a line between arrogance and verbal abuse. You have crossed that line in one big step.
Regards,
Peter van Rooijen Amsterdam
"Peter van Rooijen" squeak@vanrooijen.com wrote:
At the same time, there is a line between arrogance and verbal abuse. You have crossed that line in one big step.
Oh dear, that certainly wasn't intentional. Apologies for what must be a serious humour-impedance mismatch. It happens sometimes between people with different tastes and backgrounds, not to mention languages.
Believe me, if I really _intended_ to be rude it would be very obvious!
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Her modem lights are on but there's no carrier.
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Tim Rowledge" tim@sumeru.stanford.edu [snip]
You are correct, I don't need to lecture you on how Smalltalk works. It
also
goes without saying that since you have been 'making it professionally
for
twenty years', your judgments about it are much more valuable than
whatever
opinion I might have about it.
Excessive humility is at least as big a sin as excessive pride. Say three Hail Alans and write out the morphic hierarchy 100 times in expiation.
Tim, I have no problem with you, or anyone else, displaying arrogance. In fact, in most instances, I will enjoy it.
At the same time, there is a line between arrogance and verbal abuse. You have crossed that line in one big step.
Peter - I am pretty sure Tim was joking for most part here. I thought it was pretty funny to read. And you *did* sound pretty ironic (the sentence beginning with "You are correct, ...") so a little "punchback" was just to be expected IMHO.
Come on now guys, shake hands and let us continue. :-)
Regards,
Peter van Rooijen Amsterdam
regards, Göran
From: goran.krampe@bluefish.se
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Tim Rowledge" tim@sumeru.stanford.edu [snip]
You are correct, I don't need to lecture you on how Smalltalk works.
It
also
goes without saying that since you have been 'making it
professionally
for
twenty years', your judgments about it are much more valuable than
whatever
opinion I might have about it.
Excessive humility is at least as big a sin as excessive pride. Say three Hail Alans and write out the morphic hierarchy 100 times in expiation.
Tim, I have no problem with you, or anyone else, displaying arrogance.
In
fact, in most instances, I will enjoy it.
At the same time, there is a line between arrogance and verbal abuse.
You
have crossed that line in one big step.
Goran,
Peter - I am pretty sure Tim was joking for most part here.
It is of little consequence. I want to get this bug in Squeaks shared variable binding fixed. Tim can joke about it all he likes, I don't mind. I am squarely opposed, however, to not fixing a major bug because Tim has never been bothered by the bug.
I thought it was pretty funny to read. And you *did* sound pretty ironic (the sentence beginning with "You are correct, ...")
That sentence was not ironic. I meant it when I said I don't need to lecture Tim on how Smalltalk works. In both possible meanings: he does not require instruction from me, nor do I have a compulsion to instruct him.
The second sentence *was* ironic. Of course I didn't really mean it when I said his 20 years of doing Smalltalk automatically makes his opinions more valuable than mine.
Do I really need to explain this?
so a little "punchback" was just to be expected IMHO.
Had he "punched back" by giving real arguments instead of quoting his many years of experience and his fear of being confused by a correctly working facility that he doesn't see as useful anyway and would not want to use, I would have appreciated the "punchback".
Come on now guys, shake hands and let us continue. :-)
If you want to continue, I suggest you test the fix and post your findings.
Cheers,
Peter van Rooijen Amsterdam
Regards,
Peter van Rooijen Amsterdam
regards, Göran
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: goran.krampe@bluefish.se
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Tim Rowledge" tim@sumeru.stanford.edu [snip]
You are correct, I don't need to lecture you on how Smalltalk works.
It
also
goes without saying that since you have been 'making it
professionally
for
twenty years', your judgments about it are much more valuable than
whatever
opinion I might have about it.
Excessive humility is at least as big a sin as excessive pride. Say three Hail Alans and write out the morphic hierarchy 100 times in expiation.
Tim, I have no problem with you, or anyone else, displaying arrogance.
In
fact, in most instances, I will enjoy it.
At the same time, there is a line between arrogance and verbal abuse.
You
have crossed that line in one big step.
Goran,
Peter - I am pretty sure Tim was joking for most part here.
It is of little consequence. I want to get this bug in Squeaks shared variable binding fixed. Tim can joke about it all he likes, I don't mind. I am squarely opposed, however, to not fixing a major bug because Tim has never been bothered by the bug.
Eh... now I think things are getting mixed up. I think I was the one talking about "not been bothered" by the bug. And that was only regarding doing a new release of 3.6. As I understand it Tim has never been opposed to fix the bug (or has he?).
I thought it was pretty funny to read. And you *did* sound pretty ironic (the sentence beginning with "You are correct, ...")
That sentence was not ironic. I meant it when I said I don't need to lecture Tim on how Smalltalk works. In both possible meanings: he does not require instruction from me, nor do I have a compulsion to instruct him.
The second sentence *was* ironic. Of course I didn't really mean it when I said his 20 years of doing Smalltalk automatically makes his opinions more valuable than mine.
Eh, sorry, that was the sentence I was referring to.
Do I really need to explain this?
No, of course not. I was simply reacting on your rather strong words trying to get you guys to cool down. This list is a friendly list and we try hard to keep it that way.
so a little "punchback" was just to be expected IMHO.
Had he "punched back" by giving real arguments instead of quoting his many years of experience and his fear of being confused by a correctly working facility that he doesn't see as useful anyway and would not want to use, I would have appreciated the "punchback".
I was referring the the "Hail Alans" etc, not anything else. And again you are assuming that Squeak is meant to be nothing more than a "Smalltalk". I have posted on that issue. What I mean is that "correctly working" is clearly up for debate.
Come on now guys, shake hands and let us continue. :-)
If you want to continue, I suggest you test the fix and post your findings.
I have no idea what you are implying by this last sentence. AFAICT there is an ongoing discussion and I am following it. And the day has not come yet when people can simply tell me what to do unless they pay me.
regards, Göran
From: goran.krampe@bluefish.se
"Peter van Rooijen" squeak@vanrooijen.com wrote:
I want to get this bug in Squeaks shared variable binding fixed. Tim can joke about it all he likes, I don't
mind. I
am squarely opposed, however, to not fixing a major bug because Tim has never been bothered by the bug.
Eh... now I think things are getting mixed up. I think I was the one talking about "not been bothered" by the bug. And that was only regarding doing a new release of 3.6. As I understand it Tim has never been opposed to fix the bug (or has he?).
I don't know what his position is. My position is clear: I believe it is a bug, I want a fix incorporated in the disctibution, I have written a fix.
I am encouraged that you call it a 'bug' :-).
[snip]
No, of course not. I was simply reacting on your rather strong words trying to get you guys to cool down. This list is a friendly list and we try hard to keep it that way.
I'm all with you.
I was referring the the "Hail Alans" etc, not anything else.
Exactly. I thought those remarks at that moment were too strong for this friendly list.
And again you are assuming that Squeak is meant to be nothing more than a "Smalltalk".
I'm not making that assumption. In fact, I haven't stated my reasons for wanting this behavior changed. Also, I don't remember anyone asking me why I wanted it.
I believe I did make references to the Blue Book, to the ANSI Smalltalk standard, and the behavior of several Smalltalk implementations, which have the scope rules as I have proposed them to be changed for Squeak. If those references support my case for the change I advocate, that would be very useful.
Does that mean I am assuming that Squeak is meant to be no more than a "Smalltalk"? Of course not.
I have no opinion on what Squeak is or is not 'meant to be'.
I do generally favor increasing compatibility between Smalltalk implementations. This follows from my belief that the walls between dialects are barriers that make for a weaker Smalltalk community, because it ends up divided into subcommunities along dialect lines.
I have posted on that issue. What I mean is that "correctly working" is clearly up for debate.
I don't disagree with you here. I could make an argument that there are very good reasons for the scope rules as found in the Blue Book, the ANSI standard, and other Smalltalk dialects. They are not desirable simply because they are 'standard', they in fact have many desirable properties.
Come on now guys, shake hands and let us continue. :-)
If you want to continue, I suggest you test the fix and post your
findings.
I have no idea what you are implying by this last sentence.
I don't know that I'm implying anything. If you want to move forward, I suggested that a good way would be to test the fix I proposed and post your findings.
Perhaps an implication, if you want to call it that, is that I believe it is more useful to try out what I have proposed, instead of speculating what terrible things could conceivably happen if it gets into the image.
AFAICT there is an ongoing discussion and I am following it. And the day has not come yet when people can simply tell me what to do unless they pay me.
regards, Göran
Regards,
Peter van Rooijen Amsterdam
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: goran.krampe@bluefish.se
"Peter van Rooijen" squeak@vanrooijen.com wrote:
I want to get this bug in Squeaks shared variable binding fixed. Tim can joke about it all he likes, I don't
mind. I
am squarely opposed, however, to not fixing a major bug because Tim has never been bothered by the bug.
Eh... now I think things are getting mixed up. I think I was the one talking about "not been bothered" by the bug. And that was only regarding doing a new release of 3.6. As I understand it Tim has never been opposed to fix the bug (or has he?).
I don't know what his position is. My position is clear: I believe it is a bug, I want a fix incorporated in the disctibution, I have written a fix.
I am encouraged that you call it a 'bug' :-).
I would put it like this - if we indeed want to (as you put it) "bring Squeak in line with the Smalltalk shared variable scope rules" (ANSI) then it is a bug we should fix, and so has Tim stated in his recent posts. But if the outcome is that we instead want to have different behaviour in Squeak, then we need to do something else.
Btw, I don't like discussions where selected arguments/pieces are ignored - I stated clearly that Tim AFAIK has never said he hadn't been bothered by the bug. He simply dislikes the whole mechanism of allowing shadowing of globals. You simply elected to ignore that.
[snip]
No, of course not. I was simply reacting on your rather strong words trying to get you guys to cool down. This list is a friendly list and we try hard to keep it that way.
I'm all with you.
I was referring the the "Hail Alans" etc, not anything else.
Exactly. I thought those remarks at that moment were too strong for this friendly list.
Peter, you are editing me out of context. I can't say how insanely much I dislike that. In the previous paragraph I referred to *your* "rather strong words" and not Tim's and you know it. You are trying to make it look otherwise.
And again you are assuming that Squeak is meant to be nothing more than a "Smalltalk".
I'm not making that assumption. In fact, I haven't stated my reasons for wanting this behavior changed. Also, I don't remember anyone asking me why I wanted it.
I quote "Or is it the fact that I am trying to bring Squeak in line with the Smalltalk shared variable scope rules?".
And further:
"But would you really have others prevented from using a legitimate, well-defined, Smalltalk construct, because you fear 'a major cognitive clash', because 'our brains are not compilers'?"
And:
"Tim, I understand your example and I don't disagree that there is a potential for confusion. But this is just how Smalltalk is constructed. Classes are namespaces for their descendents. That Squeak hasn't correctly implemented this part of what Smalltalk is, does nothing to change this."
All of these quotes imply strongly that you indeed are making such an assumption and that was the reason for me bringing it onto the table.
If you are not, then ... well, you fooled me and should of course disregard everything I said on *that* matter.
[SNIP]
Come on now guys, shake hands and let us continue. :-)
If you want to continue, I suggest you test the fix and post your
findings.
I have no idea what you are implying by this last sentence.
I don't know that I'm implying anything.
Good.
I am dropping out of this discussion.
/Göran
Hi guys
this is fairly easy to have a bad email discussions (I'm expert into that). But please let us go back to normal and honest and scientific discussions.
What I would really like that if someone (with a bit of time, I know that I'm asking a lot) could sum up (not the discussion) but the ***issues***. I'm sincerly confused. I asked alex and nathanael if they looked at the issues because this is interesting for the language guys here but up until now they did not.
Stef
Hi guys!
"Peter van Rooijen" squeak@vanrooijen.com wrote: [SNIP]
Tim, I understand your example and I don't disagree that there is a potential for confusion. But this is just how Smalltalk is constructed. Classes are namespaces for their descendents. That Squeak hasn't correctly implemented this part of what Smalltalk is, does nothing to change this.
First of all - I am on Tim's side on this. I find shadowing to be a "shady business" altogether for all reasons stated. :-) Then, exactly what different kinds of shadowing we have/allow, what you can control as an author, when and how the system should warn/barf/shout etc - that is a different story. Don't intend to go there.
BUT... (finally getting to my *only* point of this post) the above text clearly shows what I consider to be two different views on what Squeak is/should be.
I think Tim views Squeak as a Smalltalk-derivative that, even though it currently is very "Smalltalk compliant", not at all *needs* to be and probably will evolve more and more away from the ANSI Smalltalk standard (this is by definition since the ANSI standard is staying put).
I may of course be wrong in this and I rely on Tim in that case telling me in his own special way. :-)
Now - this is *my* opinion:
Squeak is currently very close to Smalltalk-80 and the ANSI standard. But that is not the goal. IMHO Smalltalk is a very good language/environment - but it is after all a *dead* language if we look at the ANSI standard - it is not evolving. Of course Smalltalk compatibility is a good thing, but IMHO *only* when it doesn't hinder us from evolving Squeak into the future.
And I actually think Alan agrees on this too.
regards, Göran
Hi
I think that in any cases it would be nice to have a bunch of tests to show the specificity of Squeak, if you decide to keep it. This is fun because I was not aware of this dark aspect of Smalltalk :)
Stef
On Lundi, oct 13, 2003, at 10:58 Europe/Zurich, goran.krampe@bluefish.se wrote:
Hi guys!
"Peter van Rooijen" squeak@vanrooijen.com wrote: [SNIP]
Tim, I understand your example and I don't disagree that there is a potential for confusion. But this is just how Smalltalk is constructed. Classes are namespaces for their descendents. That Squeak hasn't correctly implemented this part of what Smalltalk is, does nothing to change this.
First of all - I am on Tim's side on this. I find shadowing to be a "shady business" altogether for all reasons stated. :-) Then, exactly what different kinds of shadowing we have/allow, what you can control as an author, when and how the system should warn/barf/shout etc - that is a different story. Don't intend to go there.
BUT... (finally getting to my *only* point of this post) the above text clearly shows what I consider to be two different views on what Squeak is/should be.
I think Tim views Squeak as a Smalltalk-derivative that, even though it currently is very "Smalltalk compliant", not at all *needs* to be and probably will evolve more and more away from the ANSI Smalltalk standard (this is by definition since the ANSI standard is staying put).
I may of course be wrong in this and I rely on Tim in that case telling me in his own special way. :-)
Now - this is *my* opinion:
Squeak is currently very close to Smalltalk-80 and the ANSI standard. But that is not the goal. IMHO Smalltalk is a very good language/environment - but it is after all a *dead* language if we look at the ANSI standard - it is not evolving. Of course Smalltalk compatibility is a good thing, but IMHO *only* when it doesn't hinder us from evolving Squeak into the future.
And I actually think Alan agrees on this too.
regards, Göran
I don't care a fig what any standard says, it's foolish.
+1
- Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Sunday, October 12, 2003 11:03 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [FIX] ClassVarsFix-petervr (was: Sharedvariablesbinding/lookupbug)
"Peter van Rooijen" squeak@vanrooijen.com wrote:
What exactly do you mean by "it", which you consider so dangerous?
Is it the fact that class variables shadow pool variables
shadow global
variables (i.e., part of the Smalltalk shared variable scope rules)?
Yes. I think it's a really stupid thing to do. It doesn't matter if it is technically within any 'standard rules'. It's just plain dumb t do it.
Worse yet it makes a possibility that two bits of code that look very similar
can refer to
quite different variables.
That is indeed how Smalltalk works, yes.
You don't need to lecture me on how Smalltalk works. I've been making it professionally for twenty years.
Even worse, the time-order of compiling methods could result in some refering to the global and
some to the
classvariable.
No, it can't, unless there are bugs in the implementation
(which currently
probably do exist because it seems that this has not been
given attention
before). The scope rules are unambiguous. So, what you are
saying is not a
complaint against the scope rules.
Compile a method referring to a Foo global. Add a class variable Foo to the same class. (Squeak objects to this, I'm happy to see.) Compile another method referring to 'Foo'.
What do you expect to be the result?
All in all, a terribly bad thing.
In your view, is it so terribly bad that you would also
want to prohibit
people from defining globals with the same name as an existing class variable or pool variable?
Until and unless there is a clearly visible way to differentiate them, yes I would like to prevent it.
Consider another situation:- Class A has a method referring to Foo, a global. Class B, a subclass of A, adds a class variable Foo. A method in B refers to Foo, which clearly you claim binds to the class variable. It also sends a message which resolves to the method in A which refers to Foo the global.
Now try to make any internal sense of this when you have to debug or refactor this code. Yes, I'm sure that a compiler can be made to cope with it but our brains are not compilers (and I don't care what the Forth guys claim) and I feel pretty sure such code would present a major cognitive clash.
I don't care a fig what any standard says, it's foolish.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Disc space, the final frontier!
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Anthony Hannan -
ducasse -
goran.krampe＠bluefish.se -
Peter van Rooijen -
Tim Rowledge