[squeak-dev] Protocol extension proposal: Boolean>>asBit ?
siguctua at gmail.com
Sun Dec 6 22:28:05 UTC 2009
2009/12/6 Alejandro F. Reimondo <aleReimondo at smalltalking.net>:
>>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
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:  ifFalse:)
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:  ifFalse:)
> 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
>> 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].
Igor Stasenko AKA sig.
More information about the Squeak-dev