2009/12/6 Alejandro F. Reimondo <aleReimondo at smalltalking.net>:
> 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.
>

Not sure i understood, what is your proposal how to solve this problem
(by avoiding instantiating it).
Got an example?

i have multiple places which look like:
value := xpression + (someThing isFoo ifTrue: [1] ifFalse:[0])

i could, of course make method #isFooBit
but this only means that i'll move #ifTrue:ifFalse: crap to that method.
And doomed to repeat same pattern again in any other my #isXXXBit
methods, as well as double protocol,
since sometimes i need to use #isFoo in branches.

Also, sometimes expressions look more direct:

value := xpression + (x>y  ifTrue: [1] ifFalse:[0])


> 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
>>
>>
>
> ________________________________
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.