can't optimize 'and:' (requires niladic block argument) - distraction?

Is it legitimate to implement an and: operation on an object and not
provide a block?

I have some constraint objects and have implemented #and: on them as I
want to join several constraints together.

I keep getting this distracting error in the Transcript and the warning
in my code.

If I change my code so that the parameter to my #and: is a block - it
removes the warning but my code breaks as is optimise to expect a
boolan and in my case the receiver is a Constraint.

So its seems like I'm hosed either way?

Anyone have any suggestions ? I could use a different name - but I
geneuinely think it reads better to have:

 (Greather than: 5) and: (Less than: 10)

Tim

Tim,

> Is it legitimate to implement an and: operation on an object and not
> provide a block?

I'm pretty sure that #and: is optimised in the compiler (I think there's
a list of optimised selectors in a comment somewhere but I can't find
it) and shouldn't be messed about with.

> Anyone have any suggestions ? I could use a different name - but I
> geneuinely think it reads better to have:
>
>  (Greather than: 5) and: (Less than: 10)

I'm quite keen on the #between:and: method - as in

        x between: 5 and: 10

(although I would probably name it #isBetween:and:).  I think it reads
better than things like

(x > 5) & (x < 10)
x > 5 and: [x < 10]

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

TimM wrote:

> Is it legitimate to implement an and: operation on an object and not
> provide a block?

I believe it is -- although the compiler warnings become irritating very
quickly (and also can hide valid warnings).  AFAIK, there is no simple way of
suppressing unwanted/unwarranted warnings.


> Anyone have any suggestions ? I could use a different name - but I
> geneuinely think it reads better to have:
>
>  (Greather than: 5) and: (Less than: 10)

No real solution, but I'd use a different name -- one as "nice" as I could
think of.  E.g I might try #andAlso: (which would pair rather prettily with
#andNot:), or #also: (which could be paired with #butNot:), or maybe use #&
(with no natural pair).

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:43909290$0$20540$[hidden email]...
> TimM wrote:
>
>> Is it legitimate to implement an and: operation on an object and not
>> provide a block?
>
> I believe it is

Yup. Problem is if you do happen to use a block argument, the code will
still get optimised on the assumption that the receiver is a boolean, and
then won't do what you want. #and: is a reserved selector in ANSI Smalltalk,
so I would suggest you treat it as a keyword and avoid it.

>...-- although the compiler warnings become irritating very
> quickly (and also can hide valid warnings).  AFAIK, there is no simple way
> of
> suppressing unwanted/unwarranted warnings.
>

Compiler warnings can be disabled quite easily:

Compiler disableWarning: <code>

You can find the codes in the SmalltalkParseErrorCodes pool.

I would go for #&, as used in the RBEnvironments. Binary selectors are more
convenient in expressions anyway, since they can reduce the requirement for
bracketing.

Regards

Blair

TimM wrote:

One might consider any of these workable...


(#(#and: #& #* #,) includes: selector) ifTrue: [^self require].
(#(#or: #| #+ #;,) includes: selector) ifTrue: [^self allow].
(#(#xor: #% #? #;?) includes: selector) ifTrue: [^self alternate].
(#(butNot: #&~ #*- #,!) includes: selector) ifTrue: [^self inhibit].
(#(orNot: #|~ #+- #;!) includes: selector) ifTrue: [^self excite].
(#(iff: #-> #-+ #not;?) includes: selector) ifTrue: [^self propose].
(#(nor: #&& #** #not,!) includes: selector) ifTrue: [^self reject].
(#(nand: #|| #++ #not;!) includes: selector) ifTrue: [^self serialize].


-cstb

Hey thanks for the suggestions (and to everyone else as well). I will change
my use of #and: and think about some of those suggested above.

For some of the others who made suggestions - I really want the operations
to be actual objects and not just symbols on other objects (as much as
possible). Refiying them, means I can put behavior on them and as such they
can then both do the verification for me, as well as provide the error
messages when things go wrong.

So as Blair is indicating,

(Greater than: 5) & (Less than: 10)

although it is actually an implementation of & on class Constraint, it
creates a new And constraint object something like:

& aConstraint

 ^And with: self with: aConstraint

Next week I also plan on releasing my SMock implementation that make use of
this kind of thing, to create expectations on how you interact with other
objects.

For example:

  mockery expect: 5 like: [ nameParser parse: (Kind of: String) & (Different
values) ].

Which means, I expect five calls to my nameParser object with parameters
that are Strings and have different values. I guess nots would like:

  mockery expect: 5 like: [ nameParser parse: (Kind of: String) & (Not
value: 'hello') ].
or
 mockery expect: 5 like: [ nameParser parse: (Kind of: String) &~ 'hello' ].

Blairs other suggestion are intersting too:

  mockery expect: 5 like: [ nameParser parse: (Kind of: String) also:
(Different values) ].
  mockery expect: 5 like: [ nameParser parse: (Kind of: String) andAlso:
(Different values) ].
  mockery expect: 5 like: [ nameParser parse: (Kind of: String) andNot:
(Different values) ].


 Anyone else have additional comments on the above?

Tim