2013/6/27 Levente Uzonyi le...@elte.hu
On Wed, 26 Jun 2013, Guillermo Polito wrote:
On Wed, Jun 26, 2013 at 11:20 PM, Levente Uzonyi le...@elte.hu wrote:
On Wed, 26 Jun 2013, Clément Bera wrote:
Actually this code:
True basicNew ifTrue: [ some code ]
On Jun 27, 2013, at 8:16 AM, Clément Bera bera.clem...@gmail.com wrote:
In Pharo 3 we will support conditional optimized messages ( #ifTrue:,
#ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean
receiver. However, this feature will be slow, so one should not use it too
Clément Bera wrote:
MyClass#foo
compilerOptions: #(- optInlineIf)
^ #myNonBooleanObject ifTrue: [ 1 ] ifFalse: [ 0 ]
There are different options like this one. I wrote them down here to
remember (section compilerOptions):
On Thu, 27 Jun 2013, Marcus Denker wrote:
On Jun 27, 2013, at 5:17 PM, Levente Uzonyi le...@elte.hu wrote:
On Thu, 27 Jun 2013, Marcus Denker wrote:
On Jun 27, 2013, at 8:16 AM, Clément Bera bera.clem...@gmail.com wrote:
In Pharo 3 we will support conditional optimized messages (
Boolean new- error
Boolean basicNew - is possible
should we care?
why not, let's forbid them with an error message!
= maybe you can and error to #become: on nil / true / false as well?
On 2013-06-26, at 14:20, Torsten Bergmann asta...@gmx.de wrote:
Boolean new- error
Boolean basicNew - is possible
should we care?
Because you don't know the tricks... This one should be just fine
True basicNew ifTrue: [ some code ] yourself
2013/6/26 Clément Bera bera.clem...@gmail.com
True basicNew ifTrue: [ some code ]
hehe raises NonBooleanReceiver :)
2013/6/26 Camillo Bruni camillobr...@gmail.com
why not,
works fine on the latest Pharo 3 because of Opal :)
So it is not a
true copy
;)
Anyhow - again my question, should we care and assure
common behavior with covering tests?
Bye
T.
I guess they are too many ...
At some point what would be nice is to define some class and API as
'system' or 'meta' that you can only use if you are in root mode and your
project would be in some kind of sandbox.
But this is too much work to implement this in a way stable enough for a
release..
On Jun 26, 2013, at 5:38 PM, Torsten Bergmann asta...@gmx.de wrote:
works fine on the latest Pharo 3 because of Opal :)
So it is not a
true copy
;)
Anyhow - again my question, should we care and assure
common behavior with covering tests?
I'm not sure that it is worth.
I would
On Wed, 26 Jun 2013, Clément Bera wrote:
Actually this code:
True basicNew ifTrue: [ some code ]
works fine on the latest Pharo 3 because of Opal :)
So the Opal compiler lacks important optimizations. :)
Levente
But nice trick for the old compiler :)
2013/6/26 Nicolas Cellier
On Wed, Jun 26, 2013 at 11:20 PM, Levente Uzonyi le...@elte.hu wrote:
On Wed, 26 Jun 2013, Clément Bera wrote:
Actually this code:
True basicNew ifTrue: [ some code ]
works fine on the latest Pharo 3 because of Opal :)
So the Opal compiler lacks important optimizations. :)
Not at all.
On 26 Jun 2013, at 14:20, Torsten Bergmann asta...@gmx.de wrote:
Boolean new- error
Boolean basicNew - is possible
should we care?
true, false and nil are special since they are unique constant instances, right
?
To support that notion, it would seem to be sensible to restrict
On Wed, 26 Jun 2013, Guillermo Polito wrote:
On Wed, Jun 26, 2013 at 11:20 PM, Levente Uzonyi le...@elte.hu wrote:
On Wed, 26 Jun 2013, Clément Bera wrote:
Actually this code:
True basicNew ifTrue: [ some code ]
works fine on the latest Pharo 3
14 matches
Mail list logo
