Eliot Miranda-2 wrote
> I do not mean this as a personal attack.  You are clearly a strong
> programmer and I am grateful for your participation and contributions.  I
> hope that you will see my critique of one tiny part of a valuable commit
> as a plea to avoid a slippery slope, not an attack in your abilities.  You
> have proven your abilities.  My concern for where the slope leads is
> speculative and perhaps I am wrong, but I think my concern is valid.  I
> hope to persuade you below.

Thank you for your kind words and your concern, I appreciate it :-)


Eliot Miranda-2 wrote
> I disagree strongly that we should always include “the people
> that don't know every nook and cranny of the language” for several
> reasons.  First, knowing that [] == nil is true is foundational.  It is
> extremely common.  If one does not know that [] == nil then there is lots
> of code in the system one does not understand.  You might  count the
> number of occurrences of [] and [nil].  One can always posit an ignorant
> programmer.  But whereas ignorant programmers can be enlightened, or
> better still enlighten themselves, a language that falls into disrepair
> maybe irretrievably damaged.  I grew up in Britain speaking British
> English and I live in the United States and am occasionally shocked by the
> loss of precision in the use of English here.  It has real effects.  Lots
> of people in the US think that “inflammable” means “cannot burn”; it means
> the opposite.
> 
> Would not the effect of failing to maintain high standards of literacy in
> a communal programming system is increasing doubt and uncertainty in the
> community members and verbosity and higher maintenance costs in the code?
> 
> A number of far greater thinkers than I have made simplicity a
> foundational principle. William of Occam stated, Non sunt multiplicanda
> entia sine necessitate (Entities are not to be multiplied without
> necessity).  It is attributed to Einstein that “all things should be made
> as simple as possible – but no simpler”.  And then there’s KISS (Keep It
> Simple, Stupid”.
> 
> Does this apply to [nil]?  Maybe not.  But what’s your reaction to those
> who fail to use der, die, das, dem & den correctly?  Do you feel that the
> person has something to learn or that German should be bastardized to
> compensate for their failings?


Florian Mateoc-4 wrote
> But I would also argue against [nil]. It is true that Smalltalk was meant
> to be very readable and approachable, not just
> by beginners but by children, and it is not an accident that it reads so
> much like "normal" English.
> 
> Still, blocks are not English-like, they are one of the constructs that do
> need to be learned. And I have never seen
> bugs caused by ifAbsent: []. If it is not obvious what ifAbsent: [] does,
> the reader would be driven towards looking at
> what an empty block returns, and they would learn it at that [point, as
> they should, even if they did not remember it
> initially from when it was taught. 

Well maybe I underestimated how foundational [] == nil seems to be, I'm just
rarely a fan of anything that is implicitly returned.
May just be the fact that I often write C++, where a missing return may
compile but then have undefined behavior at runtime, which has made me crazy
multiple times already. :P
As the consensus seems to be to use [] instead of [nil], I will change it
back in the next commit.


Eliot Miranda-2 wrote
> Traverse the world looking for submorphs whose models are ObjectExplorers
> and collect their ObjectExplorerWrappers.  The use of allInstances is
> indeed wrong.  Look also for Inspectors.  A PointerFinder or Inspector
> could indeed be the object holding onto something that should be garbage
> collected, and these UI objects can become disconnected from the scene
> graph, for example left in some global variable during a debugging
> session.  But think carefully about the criteria for choosing which
> PointerFinders and Inspectors are considered excludable; does one include
> those in different projects?  What about ones that are hidden or partially
> obscured behind other windows?
> 
> In general be suspicious of allInstances.  It is appropriate for schema
> evolution, where it is essential that every object of a particular class
> change shape, but for finding things, graph traversal is always going to
> be faster, and allInstances may uncover zombie objects that the garbage
> collector has yet to reclaim.  Test by timing collecting all instances of
> CompiledMethod and timing finding all CompiledMethods by traversing from
> Class rootsOfTheWorld.


Bob Arning-2 wrote
> Or even worse, instances which are held off-screen altogether, by undo
> stacks, e.g. Can't count how many times something didn't go away due to
> a ref through that path.

I was already thinking about traversing the World to collect all the
instances but it seemed a bit disproportionate effort, because I couldn't
think of a use case where allInstances might lead to a problem.
But as I see, there are a lot more problems with it than I thought.
I will try to find time in the next few days to revisit the code and change
that.

Just one more question:
I'm new to committing to the Inbox, if I change the code to not use
allInstances, what would be the best procedure to upload the changes to the
Inbox?
Should I just commit as usual, which would create a completely new thread in
the forum, or is there some way to upload the changes to the existing thread
apart from just linking to an upload of the .mcz?

Kind regards and thanks to everyone for your help ;-),
Leon



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html