[squeak-dev] Protocol extension proposal: Boolean>>asBit ?

Alejandro F. Reimondo aleReimondo at smalltalking.net
Sun Dec 6 15:26:03 UTC 2009


Hi,

>yes, yes.  But real Smalltalk programs have to interface with external
> programming languages, typically through a C-inlfuenced ABI.  In that
> context it makes sense.  I second Bert's proposal,  true asInteger == 1
> and: [false asInteger == 0].

IMHO, we have started from one concrete & repetitive situation
 and now the focus has gone to something completelly diferent, abstract,
 in the field of "ideas/ideaLs"...

Igor asked on how to solve the "problem" revealed by an expression like

 value := aComputation + (aBoolean ifTrue: [ oneConstant ] ifFalse: [ bConstant ])

The "problem is solved" if we avoid instantiating the problem.
Please consider WHY you have aBoolean there
 and define/use a name for it;
 I mean a name in correct scope (method, class, pool, etc) that is set
 to the value(s) you need for computation and use that name instead
 of "aBoolean".
Check the place you instantiated aBoolean, imo, you will find that it
 is in a place inside the same context (scope) of the expression. If it
 is not the case, you should consider it in context of a tool (foreign,
 more abstract) and provide at that level management for the naming
 schema.

Most times we can solve problems this way; rejecting the fact
 that they occurs and that make our systems more independent
 and scalable without suffering obesity.

cheers,
Ale.





  ----- Original Message ----- 
  From: Eliot Miranda 
  To: The general-purpose Squeak developers list 
  Sent: Saturday, December 05, 2009 6:09 PM
  Subject: Re: [squeak-dev] Protocol extension proposal: Boolean>>asBit ?





  On Sat, Dec 5, 2009 at 11:18 AM, David T. Lewis <lewis at mail.msen.com> wrote:

    On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
    > On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
    > >
    > >>>>>> "Bert" == Bert Freudenberg <bert at freudenbergs.de> writes:
    > >
    > > Bert> I don't think it would break any sane application. #asInteger is
    > > Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
    > > Bert> return an instance of Bit.
    > >
    > > Bert> I have not really felt the need for such a method, but I can see how
    > > Bert> it's tempting to have, in particular when porting code.
    > >
    > > It's also "according to who".  0 as false, 1 as true is only one encoding,
    > > and clearly not universal.  I've worked with systems where 0 is false,
    > > and -1 is true.
    >
    > I knew someone would bring this up ;) I also like to KISS.
    >
    > This is not about internal representation, but about doing arithmetic with
    > booleans. I don't think any other mapping than "true asInteger = 1" and
    > "false asInteger = 0" makes sense in that context.


    I don't think that arithmetic with booleans makes sense in any context.

    Is this convenience method really worth muddying up the distinction between
    numbers and booleans? Think of all the C programmers with bad habits
    (like me for example) who have had to stop and think twice about assuming
    that a number means the same thing as true or false.

    It seems to me that maintaining a clear distinction between numbers and
    booleans is a Good Idea even if it does require some extra typing.



  yes, yes.  But real Smalltalk programs have to interface with external programming languages, typically through a C-inlfuenced ABI.  In that context it makes sense.  I second Bert's proposal,  true asInteger == 1 and: [false asInteger == 0].


    $0.02

    Dave







------------------------------------------------------------------------------



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091206/51138ea1/attachment.htm


More information about the Squeak-dev mailing list