Re: [Newbies] Re: Re: error trap

[Damien Cassou]

Yes. And, into the other direction, even in good core methods one often 
finds things like


 ^ dict at: aKey ifAbsent: [nil]

There seems to be a natural confusion between object value and block 
value. 


What's the problem with that ? Yes, 'nil value' answers nil but 'nil' is 
not a block and #at:ifAbsent: waits for a block (the parameter is called 
aBlock). It is shorter to write 'nil' directly I agree.



What is more problematic in my point of view is code like this:

AbstractLauncherparameterAt: parName ifAbsent: aBlock
  Return the parameter named parName.
Evaluate the block if parameter does not exist.
  ^self parameters
at: parName asUppercase
ifAbsent: [aBlock value]



It may be me (still a beginner), but it looks equivalent to

  ^self parameters
at: parName asUppercase
ifAbsent: aBlock


which is faster and clearer in my opinion.
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Re: [Newbies] Re: Re: error trap

[stéphane ducasse]

parse into collections automatically. You didn't inspectIt for  
verifying

your (false) claim, didn't you.


No I didn't!  The { } just looked so wrong and like C!  I'm used to  
#()

which of course doesn't work.

 Also, have a look at the implementors of
#caseOf: and #caseOf:otherwise:, they are heavy users of literal  
blocks in

Collections ...


I will!


argh! Ugly!

Yes. And, into the other direction, even in good core methods one  
often

finds things like

  ^ dict at: aKey ifAbsent: [nil]


this is much better.

I would like to see caseOf:...removed from the system

I started to write this too but thought about some of the errors  
that people

receive about wrong form of block and didn't want to scare people.


stef
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners

RE: [Newbies] Re: Re: error trap

[Ron Teitelbaum]

 From: Klaus D. Witzel
 
 On Wed, 09 Aug 2006 21:11:40 +0200, Ron Teitelbaum wrote:
  Brian,
 
  Yes I agree it's a great suggestion, although a few changes:
  Literal blocks to not parse into collections automatically.
 
 Ron, please: a literal Array is a subclass of Collection and so the blocks
 in
 
   { [nil]. [true]. [false] }

Learn something every day!

 
 parse into collections automatically. You didn't inspectIt for verifying
 your (false) claim, didn't you.

No I didn't!  The { } just looked so wrong and like C!  I'm used to #()
which of course doesn't work.

 Also, have a look at the implementors of
 #caseOf: and #caseOf:otherwise:, they are heavy users of literal blocks in
 Collections ...

I will!

 
 ...
  Each in this case is already a block.
 
 Yes. And, into the other direction, even in good core methods one often
 finds things like
 
   ^ dict at: aKey ifAbsent: [nil]

I started to write this too but thought about some of the errors that people
receive about wrong form of block and didn't want to scare people.  

 
 There seems to be a natural confusion between object value and block
 value. Not a big surprise since Java and other procedural-oriented
 friends do not offer block values. So any demo of using blocks as if
 they where any other object, as Brian has shown, is a sign for the ability
 to master the subject 8-)
 
  Only each is needed.
 
 Absolutely.
 
  So here is a version that works.
 
  (OrderedCollection new
  add: [10/0];
  add: [2 raisedToInteger: 1/2];
  add: [-5 raisedTo: 1.5]; yourself
  ) do: [:each | each on: Exception do: [:ex | Transcript show: ex; cr;
  endEntry]].
 
  endEntry is for Klaus!
 
 Hhm, endEntry is too expensive within any and every loop. Just put
 Transcript endEntry after the loop. I mentioned endEntry because
 Transcript almost always does not display the last lines (they are
 buffered) and people get confused and believe that either their code or
 Squeak is wrong (but both is not the case).
 
  It is a very good suggestion Brian!
 
 Indeed, and Briant's use of literal blocks in a literal Array is perfect
 (in the sense of: cannot be made better).
 

Thanks for your correction Klaus!  With programming always keep an open
mind, there is lots more to learn!

Ron



___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners