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