[squeak-dev] Protocol extension proposal: Boolean>>asBit ?
Alejandro F. Reimondo
aleReimondo at smalltalking.net
Sun Dec 6 15:26:03 UTC 2009
>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
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
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.
----- 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].
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev