Re: [Pharo-dev] object pinning versus garbage collection

[Ben Coman]

On Sun, Sep 25, 2016 at 7:14 AM, Eliot Miranda  wrote:
> Hi Ben,
>
>> On Sep 23, 2016, at 8:17 PM, Ben Coman  wrote:
>>
>> How does object pinning interact with garbage collection?  Does it
>> block garbage collection until it is manually unpinned?  Or does it
>> garbage collection proceed anyway?  Intuitively I'd guess the former??
>
> The latter. The properties are orthogonal.  Unreachable pinned objects are 
> still unreachable.  Therefore they are garbage collected.  A use case that 
> wishes to maintain a pinned object over some time period must arrange that 
> there is a string reference to the object to define that time span.

Thanks Eliot. So we need to be careful/aware of the corner case where
an FFI callout function may store a reference to a pinned object past
the return from the callout, and arrange things as you say.

cheers -ben

Re: [Pharo-dev] object pinning versus garbage collection

[Eliot Miranda]

Hi Ben,

> On Sep 23, 2016, at 8:17 PM, Ben Coman  wrote:
> 
> How does object pinning interact with garbage collection?  Does it
> block garbage collection until it is manually unpinned?  Or does it
> garbage collection proceed anyway?  Intuitively I'd guess the former??

The latter. The properties are orthogonal.  Unreachable pinned objects are 
still unreachable.  Therefore they are garbage collected.  A use case that 
wishes to maintain a pinned object over some time period must arrange that 
there is a string reference to the object to define that time span.

> 
> cheers -ben
> 

Re: [Pharo-dev] Object>>rollToArity:?

[Esteban Lorenzano]

I’m not happy with the method name, but I think is well explained in method 
comments: 

ExternalAddress>>rollToArity: arity
"This will 'roll' a pointer to a certain arity. 
What does this means? Let's say I have a method who will be called with 
a ** arity: 

method: aPointer
self ffiCall: #( method ( MyExternalObjectClass **aPointer) )

This usually means that method will put a pointer in the address of 
aPointer. 
And what I actually want is this pointer. So I do Something like this: 

p := MyExternalObjectClass new.
self mehod: p.

And I expect to have 'p' correctly initialised on return. 
Well... tha's not so simple :)

When compiling #method:, UnifiedFFI needs to first 'roll' the pointer 
(which means to 
take a pointer of a pointer of a pointer... as many pointers as arity 
solicited), and then, 
after call, it needs to 'unroll' all this pointers (see 
#unrollFromArity: method)  
“

ByteArray>>rollToArity: arity
"This is complicated... I assuming this ways of calling a function: 
 
  arity == 1: 
---
ByteArray works as pointer buffer of single pointer to something: 
ex 1)
buffer := ByteArray new: 4.
self ffiCall: #( void function (int *buffer) ).
ex 2)
buffer := 'Hello, World' asByteArray.
self ffiCall: #( void function (char *buffer) ).

arity > 1: 
--
ByteArray works as pointer to allocate results:
ex 1)
pointer := ByteArray new: (FFIExternalType pointerSize).
self ffiCall: #( void function ( char **answer )).
   
In this case this will not work fine because content of ByteArray needs 
to be a 
pointer too, and then it needs to be allocated in the heap... while 
this could be 
managed, I'm puting for the moment just an error and a recommendation 
of using an 
ExternalAddress.
"


basically, is the equivalent of “&” operator in C. 
you can manually do the same by doing: 

| var |
var := 42 pointer.

who will give you a byte array with signedLongAt: 1 == 42.

… but since old NB was doing this implicitly, we need to provide it too :)

Esteban 

ps: Why do you need to know it? This is internal in UnifiedFFI so nobody should 
need to deal with it.

> On 17 Feb 2016, at 16:49, Alexandre Bergel  wrote:
> 
> Esteban, 
> 
> What Object>>rollToArity: is supposed to do? It belongs to UnifiedFFI
> 
> Cheers,
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Object graph stream/visitor implementation?

[Tudor Girba]

Hi,

Indeed, DeepTraverser is the project to look at. I started it from the code of 
Mariano, and then Stefan Rechhart reimplemented it from scratch to make it very 
fast (e.g. traversing subclasses of a class is only 10% slower than the hard 
coded withAllSubclassesDo:) and to make it work like a stream. It's really 
beautiful.

Cheers,
Doru

--
www.tudorgirba.com

"Every thing has its own flow"

> On 22 Dec 2015, at 14:06, Mariano Martinez Peck  wrote:
> 
> Denis,
> 
> The DeepTraverser was a little easy hack I shared years ago to Tudor Girba 
> which he then (improved it?) put it in Moose.
> While it works is still very limited. You can give it a try. And if not, 
> please spend some time checking the graph traverser we have in Fuel. I 
> suspect it could be easily adapted for custom code, but I am not sure ;)
> 
> Basically, check FLAnalysis >> run, which has a stack and starts the trace 
> via #mapAndTrace: 
> 
> Cheers,
> 
>> On Tue, Dec 22, 2015 at 6:20 AM, Denis Kudriashov  
>> wrote:
>> I found this: http://smalltalkhub.com/#!/~Moose/DeepTraverser
>> 
>> 2015-12-22 10:05 GMT+01:00 Marcus Denker :
>>> 
>>> > On 22 Dec 2015, at 09:46, Denis Kudriashov  wrote:
>>> >
>>> > Hello.
>>> >
>>> > Do we have way to traverse object graph?
>>> >
>>> > I want stream which iterate object graph through instance variables with 
>>> > knowledge about path at every step.
>>> >
>>> > Maybe Fuel has classes for this ?
>>> >
>>> 
>>> yes, I think so.. there is #fuelAccept:, but I am not sure how general it 
>>> is.
>>> 
>>> I remember that Doru did some object graph iteration experiments, too?
>>> (I can’t find it).
>>> 
>>> But I think we should actually add a general “object graph iterator” to the 
>>> reflective
>>> features of the language. It seems very useful to have, and for sure Fuel 
>>> could just
>>> use it.
>>> 
>>> Marcus
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-dev] Object graph stream/visitor implementation?

[Robert Withers]

I managed to get per object substitution callbacks working in Mushroom. 
Please take a look in http://www.squeaksource.com/Mushroom and load 
Mushr00m-Pharo on top of MushrOOm (after installing Cryptography and 
SecureSession from http://www.squeaksource.com/Cryptography).


Then look at the classes in the Utility category.

HTH,

Robert



On 12/22/2015 03:46 AM, Denis Kudriashov wrote:

Hello.

Do we have way to traverse object graph?

I want stream which iterate object graph through instance variables 
with knowledge about path at every step.


Maybe Fuel has classes for this ?

Best regards,
Denis


--
. ..  ...   ^,^robert
Go Panthers!

Re: [Pharo-dev] Object graph stream/visitor implementation?

[Robert Withers]

I'm sorry, this is with Fuel loaded. These are extensions to Fuel 
serialization and materialization.



b, robert


On 12/22/2015 03:55 AM, Robert Withers wrote:
I managed to get per object substitution callbacks working in 
Mushroom. Please take a look in http://www.squeaksource.com/Mushroom 
and load Mushr00m-Pharo on top of MushrOOm (after installing 
Cryptography and SecureSession from 
http://www.squeaksource.com/Cryptography).


Then look at the classes in the Utility category.

HTH,

Robert



On 12/22/2015 03:46 AM, Denis Kudriashov wrote:

Hello.

Do we have way to traverse object graph?

I want stream which iterate object graph through instance variables 
with knowledge about path at every step.


Maybe Fuel has classes for this ?

Best regards,
Denis




--
. ..  ...   ^,^robert
Go Panthers!

Re: [Pharo-dev] Object graph stream/visitor implementation?

[Marcus Denker]

> On 22 Dec 2015, at 09:46, Denis Kudriashov  wrote:
> 
> Hello.
> 
> Do we have way to traverse object graph?
> 
> I want stream which iterate object graph through instance variables with 
> knowledge about path at every step.
> 
> Maybe Fuel has classes for this ?
> 

yes, I think so.. there is #fuelAccept:, but I am not sure how general it is.

I remember that Doru did some object graph iteration experiments, too?
(I can’t find it).

But I think we should actually add a general “object graph iterator” to the 
reflective 
features of the language. It seems very useful to have, and for sure Fuel could 
just
use it.

Marcus

Re: [Pharo-dev] Object graph stream/visitor implementation?

[Denis Kudriashov]

I found this: http://smalltalkhub.com/#!/~Moose/DeepTraverser

2015-12-22 10:05 GMT+01:00 Marcus Denker :

>
> > On 22 Dec 2015, at 09:46, Denis Kudriashov  wrote:
> >
> > Hello.
> >
> > Do we have way to traverse object graph?
> >
> > I want stream which iterate object graph through instance variables with
> knowledge about path at every step.
> >
> > Maybe Fuel has classes for this ?
> >
>
> yes, I think so.. there is #fuelAccept:, but I am not sure how general it
> is.
>
> I remember that Doru did some object graph iteration experiments, too?
> (I can’t find it).
>
> But I think we should actually add a general “object graph iterator” to
> the reflective
> features of the language. It seems very useful to have, and for sure Fuel
> could just
> use it.
>
> Marcus
>
>
>
>
>

Re: [Pharo-dev] Object graph stream/visitor implementation?

[Mariano Martinez Peck]

Denis,

The DeepTraverser was a little easy hack I shared years ago to Tudor Girba
which he then (improved it?) put it in Moose.
While it works is still very limited. You can give it a try. And if not,
please spend some time checking the graph traverser we have in Fuel. I
suspect it could be easily adapted for custom code, but I am not sure ;)

Basically, check FLAnalysis >> run, which has a stack and starts the trace
via #mapAndTrace:

Cheers,

On Tue, Dec 22, 2015 at 6:20 AM, Denis Kudriashov 
wrote:

> I found this: http://smalltalkhub.com/#!/~Moose/DeepTraverser
>
> 2015-12-22 10:05 GMT+01:00 Marcus Denker :
>
>>
>> > On 22 Dec 2015, at 09:46, Denis Kudriashov 
>> wrote:
>> >
>> > Hello.
>> >
>> > Do we have way to traverse object graph?
>> >
>> > I want stream which iterate object graph through instance variables
>> with knowledge about path at every step.
>> >
>> > Maybe Fuel has classes for this ?
>> >
>>
>> yes, I think so.. there is #fuelAccept:, but I am not sure how general it
>> is.
>>
>> I remember that Doru did some object graph iteration experiments, too?
>> (I can’t find it).
>>
>> But I think we should actually add a general “object graph iterator” to
>> the reflective
>> features of the language. It seems very useful to have, and for sure Fuel
>> could just
>> use it.
>>
>> Marcus
>>
>>
>>
>>
>>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Object #is:

[Esteban Lorenzano]

On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:

 
 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:
 
 the isBlah is not optimal now it is just there and we cannot rewrite 
 everything. 
 I still think that is: is a nice way to kill some of the isPlague in Object.
 
 I still don't see what you solve, and the idea to use symbols for #is: is also
 wrong, for me that's going back to string-based programming.

well, that's basically my argument agains #is: 
IMO is also an important performance issue in many cases, because is replacing 
a simple send with a string comparison and that can provoke slowdowns in some 
places (no idea where,  this is just theoretical :)...
Of course, as pharo designers we should be careful on not overpopulate Object 
with isBlah methods... but sometimes they are needed :)

TL;DR: I agree with Camillo :)

 
 anyway, this topic has been discussed with enough hot air so far and no 
 progress, 
 which means it is absolutely not important. there are more urgent things to 
 done...

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 10:51, Esteban Lorenzano esteba...@gmail.com wrote:

 On Jun 25, 2013, at 10:47 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 10:28, Esteban Lorenzano esteba...@gmail.com wrote:

 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:


 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr 
 wrote:

 the isBlah is not optimal now it is just there and we cannot rewrite 
 everything.
 I still think that is: is a nice way to kill some of the isPlague in 
 Object.

 I still don't see what you solve, and the idea to use symbols for #is: is 
 also
 wrong, for me that's going back to string-based programming.

 well, that's basically my argument agains #is:
 IMO is also an important performance issue in many cases, because is 
 replacing a simple send with a string comparison and that can provoke 
 slowdowns in some places (no idea where,  this is just theoretical :)...
 Of course, as pharo designers we should be careful on not overpopulate 
 Object with isBlah methods... but sometimes they are needed :)

 yes, but please, do that, after you remove rest of isXXX methods in Object :)

 which rest?


Object selectors select: [ :each | each beginsWith: 'is' ]

 #(#isThisEverCalled #isMorphicEvent #isCollection #isSpecLayout
#isCodeCompletionAllowed #isComplex #isTransferable #isLiteral
#isKindOf: #isInterval #isMorphicModel #isStream #isMorph #isPoint
#isTrait #isCompiledMethod #isCharacter #isMessageSend #isText
#isBlock #isRectangle #isContext #isBehavior #isArray
#isVariableBinding #isColorForm #isSymbol #isDictionary #isHeap
#isNumber #isSystemWindow #isThisEverCalled: #isString #isNotNil
#isRingObject #isMethodProperties #isInteger #isFraction #isColor #is:
#isClosure #isFloat #isMemberOf: #isForm #isSelfEvaluating)

you welcome :)


 TL;DR: I agree with Camillo :)




 anyway, this topic has been discussed with enough hot air so far and no 
 progress,
 which means it is absolutely not important. there are more urgent things 
 to done...





 --
 Best regards,
 Igor Stasenko.






-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Esteban Lorenzano]

On Jun 25, 2013, at 10:54 AM, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 10:51, Esteban Lorenzano esteba...@gmail.com wrote:
 
 On Jun 25, 2013, at 10:47 AM, Igor Stasenko siguc...@gmail.com wrote:
 
 On 25 June 2013 10:28, Esteban Lorenzano esteba...@gmail.com wrote:
 
 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:
 
 
 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr 
 wrote:
 
 the isBlah is not optimal now it is just there and we cannot rewrite 
 everything.
 I still think that is: is a nice way to kill some of the isPlague in 
 Object.
 
 I still don't see what you solve, and the idea to use symbols for #is: is 
 also
 wrong, for me that's going back to string-based programming.
 
 well, that's basically my argument agains #is:
 IMO is also an important performance issue in many cases, because is 
 replacing a simple send with a string comparison and that can provoke 
 slowdowns in some places (no idea where,  this is just theoretical :)...
 Of course, as pharo designers we should be careful on not overpopulate 
 Object with isBlah methods... but sometimes they are needed :)
 
 yes, but please, do that, after you remove rest of isXXX methods in Object 
 :)
 
 which rest?
 
 
 Object selectors select: [ :each | each beginsWith: 'is' ]
 
 #(#isThisEverCalled #isMorphicEvent #isCollection #isSpecLayout
 #isCodeCompletionAllowed #isComplex #isTransferable #isLiteral
 #isKindOf: #isInterval #isMorphicModel #isStream #isMorph #isPoint
 #isTrait #isCompiledMethod #isCharacter #isMessageSend #isText
 #isBlock #isRectangle #isContext #isBehavior #isArray
 #isVariableBinding #isColorForm #isSymbol #isDictionary #isHeap
 #isNumber #isSystemWindow #isThisEverCalled: #isString #isNotNil
 #isRingObject #isMethodProperties #isInteger #isFraction #isColor #is:
 #isClosure #isFloat #isMemberOf: #isForm #isSelfEvaluating)
 
 you welcome :)

I know that... but my point is that many of them are ok, and are clearer that 
some more obscure #is: implementation. 
I do not see the win on remove them, honestly... IMO is an unnecessary clean 
that contributes to create less readable core, in the best of cases. 



 
 
 TL;DR: I agree with Camillo :)
 
 
 
 
 anyway, this topic has been discussed with enough hot air so far and no 
 progress,
 which means it is absolutely not important. there are more urgent things 
 to done...
 
 
 
 
 
 --
 Best regards,
 Igor Stasenko.
 
 
 
 
 
 
 -- 
 Best regards,
 Igor Stasenko.
 

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote:

 On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:


 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:


 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:


 the isBlah is not optimal now it is just there and we cannot rewrite
 everything.

 I still think that is: is a nice way to kill some of the isPlague in Object.


 I still don't see what you solve, and the idea to use symbols for #is: is
 also

 wrong, for me that's going back to string-based programming.


 well, that's basically my argument agains #is:
 IMO is also an important performance issue in many cases, because is
 replacing a simple send with a string comparison and that can provoke
 slowdowns in some places (no idea where,  this is just theoretical :)...
 Of course, as pharo designers we should be careful on not overpopulate
 Object with isBlah methods... but sometimes they are needed :)


 +1.
 Indeed, sometimes they are needed. You can't replace every isXXX send with a
 new visitor or dispatching by adding more and more extension methods all
 over the place (including Object BTW).
 Yet a fair amount of these methods can be removed.
 I think that a lot of these methods exist only because people think that
 isKindOf:/isMemberOf: are always evil, and its not true.
 There is at least three cases were I don't feel guilty using
 isKindOf:/isMemberOf: :
 - In unit tests
 - In #= methods
 - When I really want to ensure that an object is an instance of a specific
 class (see MethodContext#privRefreshWith: for example). This poor's man
 type checking can be replace with typed slots (that end up using
 isKindOf/isMemberOf: anyway).
 If we agree on that we can remove many #isXXX methods.
 Then there is some #isXXX methods that do not belong to Object (ex:
 #isTransferable belongs to Morph) and others that can be removed just by
 refactoring senders.
 We can also move some of them to extension methods, that doesn't solve the
 problem but it's a better packaging.
 Anyway I don't want to rely on #is: method because it conflates a lot of
 selectors into one.

yes. it is. so what is the problem?

Are you sure you understand the purpose of #is: method?
its purpose is for cases when you realy realy very very badly want to
add own isPlague to
Object protocol. In that case, you should use 'is: #plague'
because no new is methods should be added anymore.
The feast is over, and you should use #is: method. (or think how to
not use isXXX pattern at all).


 TL;DR: I agree with Camillo :)


 anyway, this topic has been discussed with enough hot air so far and no
 progress,

 which means it is absolutely not important. there are more urgent things to
 done...



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Henrik Johansen]

On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote:

 
 On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
 
 
 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:
 
 
 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:
 
 the isBlah is not optimal now it is just there and we cannot rewrite 
 everything. 
 I still think that is: is a nice way to kill some of the isPlague in 
 Object.
 
 I still don't see what you solve, and the idea to use symbols for #is: is 
 also
 wrong, for me that's going back to string-based programming.
 
 well, that's basically my argument agains #is: 
 IMO is also an important performance issue in many cases, because is 
 replacing a simple send with a string comparison and that can provoke 
 slowdowns in some places (no idea where,  this is just theoretical :)...
 Of course, as pharo designers we should be careful on not overpopulate 
 Object with isBlah methods... but sometimes they are needed :)
 
 +1.
 Indeed, sometimes they are needed. You can't replace every isXXX send with a 
 new visitor or dispatching by adding more and more extension methods all over 
 the place (including Object BTW).

While dispatch is a valid substitute, it:
1) Doesn't pollute Object any less, like you say (you still need a handleXYZ: 
method on Object replacing the previous isX, now doing nothing)
2) Breaks up the flow of the code, making it harder to get a good picture 
without 948 implementors open.

 Yet a fair amount of these methods can be removed.
 I think that a lot of these methods exist only because people think that 
 isKindOf:/isMemberOf: are always evil, and its not true.
 There is at least three cases were I don't feel guilty using 
 isKindOf:/isMemberOf: :
 - In unit tests
 - In #= methods
 - When I really want to ensure that an object is an instance of a specific 
 class (see MethodContext#privRefreshWith: for example). This poor's man 
 type checking can be replace with typed slots (that end up using 
 isKindOf/isMemberOf: anyway).

For me, this has the same fundamental problem as using is:.
If you were to, for example, write isKindOf: Number instead of isNumber, try 
quickly identifying the places that is being used without doing a full text 
search.
You can't search for Number, lest you want to sift through all references to 
the class,  and you can't search for isKindOf: without wading through its uses 
with all other classes.
The degree to which this is a problem differs of course.

 If we agree on that we can remove many #isXXX methods.
 Then there is some #isXXX methods that do not belong to Object (ex: 
 #isTransferable belongs to Morph) and others that can be removed just by 
 refactoring senders.
 We can also move some of them to extension methods, that doesn't solve the 
 problem but it's a better packaging.
 Anyway I don't want to rely on #is: method because it conflates a lot of 
 selectors into one. 

+1
The longer I maintain Smalltalk code, the more I appreciate specific selectors 
like #fromADomainObject: / #atMyTypeOfData:. 
Makes refactoring and reasoning about a dead image much, much, easier.

Having my Object class unpolluted comes much further down my list of nice to 
haves, if it can't be rewritten/safely hoisted to an appropriate subclass, 
making them extensions are more than enough imho.

Cheers,
Henry

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 11:54, Henrik Johansen henrik.s.johan...@veloxit.no wrote:

 On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote:


 On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:


 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:


 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:


 the isBlah is not optimal now it is just there and we cannot rewrite
 everything.

 I still think that is: is a nice way to kill some of the isPlague in Object.


 I still don't see what you solve, and the idea to use symbols for #is: is
 also

 wrong, for me that's going back to string-based programming.


 well, that's basically my argument agains #is:
 IMO is also an important performance issue in many cases, because is
 replacing a simple send with a string comparison and that can provoke
 slowdowns in some places (no idea where,  this is just theoretical :)...
 Of course, as pharo designers we should be careful on not overpopulate
 Object with isBlah methods... but sometimes they are needed :)


 +1.
 Indeed, sometimes they are needed. You can't replace every isXXX send with a
 new visitor or dispatching by adding more and more extension methods all
 over the place (including Object BTW).


 While dispatch is a valid substitute, it:
 1) Doesn't pollute Object any less, like you say (you still need a
 handleXYZ: method on Object replacing the previous isX, now doing nothing)
 2) Breaks up the flow of the code, making it harder to get a good picture
 without 948 implementors open.

 Yet a fair amount of these methods can be removed.
 I think that a lot of these methods exist only because people think that
 isKindOf:/isMemberOf: are always evil, and its not true.
 There is at least three cases were I don't feel guilty using
 isKindOf:/isMemberOf: :
 - In unit tests
 - In #= methods
 - When I really want to ensure that an object is an instance of a specific
 class (see MethodContext#privRefreshWith: for example). This poor's man
 type checking can be replace with typed slots (that end up using
 isKindOf/isMemberOf: anyway).


 For me, this has the same fundamental problem as using is:.
 If you were to, for example, write isKindOf: Number instead of isNumber, try
 quickly identifying the places that is being used without doing a full text
 search.
 You can't search for Number, lest you want to sift through all references to
 the class,  and you can't search for isKindOf: without wading through its
 uses with all other classes.
 The degree to which this is a problem differs of course.


#is: method does not have such problem.
Objectis: foo
  ^ false

MyClassis: foo
  ^ foo == #specialName


to look for all uses of #specialName, you can just browse senders of it.
And it will give you exact number and places, without need to do a
full-text search. Simple and easy isn't?

That's of course, how i would use it...
But when people proposing to add some 'more useful' forms
of it, like comparing class name, or class , or even strings, in
default implementation, things get more complicated,
and you no longer sure how to find all uses for your case.
Instead, if we keep things simple and restrict that parameter should
be a symbol, and default implementation (in Object) always answers
false,
this will make things much easier to deal with in foreseen future.

Now, if people do not like it, and do not want it.. so, lets keep
using our beloved isKindOf: and friends..
every time i see how people use them, i get a warm fuzzy feeling :)

 If we agree on that we can remove many #isXXX methods.
 Then there is some #isXXX methods that do not belong to Object (ex:
 #isTransferable belongs to Morph) and others that can be removed just by
 refactoring senders.
 We can also move some of them to extension methods, that doesn't solve the
 problem but it's a better packaging.
 Anyway I don't want to rely on #is: method because it conflates a lot of
 selectors into one.


 +1
 The longer I maintain Smalltalk code, the more I appreciate specific
 selectors like #fromADomainObject: / #atMyTypeOfData:.
 Makes refactoring and reasoning about a dead image much, much, easier.

 Having my Object class unpolluted comes much further down my list of nice
 to haves, if it can't be rewritten/safely hoisted to an appropriate
 subclass, making them extensions are more than enough imho.


In general, the more methods we put into Object, the higher
probability of name clashing (two projects using same selector
for method in Object but for different purpose).
It also slows down the lookup time, because VM checks every method
dictionary, including Object.
(not speaking of slowing down UI ;)

 Cheers,
 Henry


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Nicolas Cellier]

But in some cases, you will end up with an object that is more than one
thing:
- a Number
- an Integer
- a Fraction
For example 0 shall answer yes to these 3.
So ^foo == #specialName just does not work, or you end up with caseOf:


2013/6/25 Igor Stasenko siguc...@gmail.com

 On 25 June 2013 11:54, Henrik Johansen henrik.s.johan...@veloxit.no
 wrote:
 
  On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote:
 
 
  On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
 
 
  On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com
 wrote:
 
 
  On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr
 wrote:
 
 
  the isBlah is not optimal now it is just there and we cannot rewrite
  everything.
 
  I still think that is: is a nice way to kill some of the isPlague in
 Object.
 
 
  I still don't see what you solve, and the idea to use symbols for #is: is
  also
 
  wrong, for me that's going back to string-based programming.
 
 
  well, that's basically my argument agains #is:
  IMO is also an important performance issue in many cases, because is
  replacing a simple send with a string comparison and that can provoke
  slowdowns in some places (no idea where,  this is just theoretical :)...
  Of course, as pharo designers we should be careful on not overpopulate
  Object with isBlah methods... but sometimes they are needed :)
 
 
  +1.
  Indeed, sometimes they are needed. You can't replace every isXXX send
 with a
  new visitor or dispatching by adding more and more extension methods all
  over the place (including Object BTW).
 
 
  While dispatch is a valid substitute, it:
  1) Doesn't pollute Object any less, like you say (you still need a
  handleXYZ: method on Object replacing the previous isX, now doing
 nothing)
  2) Breaks up the flow of the code, making it harder to get a good picture
  without 948 implementors open.
 
  Yet a fair amount of these methods can be removed.
  I think that a lot of these methods exist only because people think that
  isKindOf:/isMemberOf: are always evil, and its not true.
  There is at least three cases were I don't feel guilty using
  isKindOf:/isMemberOf: :
  - In unit tests
  - In #= methods
  - When I really want to ensure that an object is an instance of a
 specific
  class (see MethodContext#privRefreshWith: for example). This poor's man
  type checking can be replace with typed slots (that end up using
  isKindOf/isMemberOf: anyway).
 
 
  For me, this has the same fundamental problem as using is:.
  If you were to, for example, write isKindOf: Number instead of isNumber,
 try
  quickly identifying the places that is being used without doing a full
 text
  search.
  You can't search for Number, lest you want to sift through all
 references to
  the class,  and you can't search for isKindOf: without wading through its
  uses with all other classes.
  The degree to which this is a problem differs of course.
 

 #is: method does not have such problem.
 Objectis: foo
   ^ false

 MyClassis: foo
   ^ foo == #specialName


 to look for all uses of #specialName, you can just browse senders of it.
 And it will give you exact number and places, without need to do a
 full-text search. Simple and easy isn't?

 That's of course, how i would use it...
 But when people proposing to add some 'more useful' forms
 of it, like comparing class name, or class , or even strings, in
 default implementation, things get more complicated,
 and you no longer sure how to find all uses for your case.
 Instead, if we keep things simple and restrict that parameter should
 be a symbol, and default implementation (in Object) always answers
 false,
 this will make things much easier to deal with in foreseen future.

 Now, if people do not like it, and do not want it.. so, lets keep
 using our beloved isKindOf: and friends..
 every time i see how people use them, i get a warm fuzzy feeling :)

  If we agree on that we can remove many #isXXX methods.
  Then there is some #isXXX methods that do not belong to Object (ex:
  #isTransferable belongs to Morph) and others that can be removed just by
  refactoring senders.
  We can also move some of them to extension methods, that doesn't solve
 the
  problem but it's a better packaging.
  Anyway I don't want to rely on #is: method because it conflates a lot of
  selectors into one.
 
 
  +1
  The longer I maintain Smalltalk code, the more I appreciate specific
  selectors like #fromADomainObject: / #atMyTypeOfData:.
  Makes refactoring and reasoning about a dead image much, much, easier.
 
  Having my Object class unpolluted comes much further down my list of
 nice
  to haves, if it can't be rewritten/safely hoisted to an appropriate
  subclass, making them extensions are more than enough imho.
 

 In general, the more methods we put into Object, the higher
 probability of name clashing (two projects using same selector
 for method in Object but for different purpose).
 It also slows down the lookup time, because VM checks every method
 

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 12:47, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
 But in some cases, you will end up with an object that is more than one
 thing:
 - a Number
 - an Integer
 - a Fraction
 For example 0 shall answer yes to these 3.
 So ^foo == #specialName just does not work, or you end up with caseOf:


err, why?

if you define it like:

Numberis: symbol
  ^ symbol == #number


0 is: #number = true
0.0 is: #number = true
0/1  is: #number = true
?

It is actually up to implementor how to his own classes should process
#is: message.
The only invariant (which imo best one), that Object should always
answer false to #is: message no matter what parameter you passed, to
avoid any ambiguous cases and keep things simple and easy to remember.
That means, that unless you override this method in own class, its
instances will always answer false to #is: message.
And when you override it, you are free to define it the way you like...

MyClassis: foo
  ^ foo class == self class
or
MyClassis: foo
  ^ foo class name == self class name
or

MyClassis: foo
  ^ foo isKindOf: MyClass

(no limits to imagination :)

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 12:59, Camille Teruel camille.ter...@gmail.com wrote:

 On 25 juin 2013, at 11:45, Igor Stasenko wrote:

 On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote:


 On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:



 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:



 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:



 the isBlah is not optimal now it is just there and we cannot rewrite

 everything.


 I still think that is: is a nice way to kill some of the isPlague in Object.



 I still don't see what you solve, and the idea to use symbols for #is: is

 also


 wrong, for me that's going back to string-based programming.



 well, that's basically my argument agains #is:

 IMO is also an important performance issue in many cases, because is

 replacing a simple send with a string comparison and that can provoke

 slowdowns in some places (no idea where,  this is just theoretical :)...

 Of course, as pharo designers we should be careful on not overpopulate

 Object with isBlah methods... but sometimes they are needed :)



 +1.

 Indeed, sometimes they are needed. You can't replace every isXXX send with a

 new visitor or dispatching by adding more and more extension methods all

 over the place (including Object BTW).

 Yet a fair amount of these methods can be removed.

 I think that a lot of these methods exist only because people think that

 isKindOf:/isMemberOf: are always evil, and its not true.

 There is at least three cases were I don't feel guilty using

 isKindOf:/isMemberOf: :

 - In unit tests

 - In #= methods

 - When I really want to ensure that an object is an instance of a specific

 class (see MethodContext#privRefreshWith: for example). This poor's man

 type checking can be replace with typed slots (that end up using

 isKindOf/isMemberOf: anyway).

 If we agree on that we can remove many #isXXX methods.

 Then there is some #isXXX methods that do not belong to Object (ex:

 #isTransferable belongs to Morph) and others that can be removed just by

 refactoring senders.

 We can also move some of them to extension methods, that doesn't solve the

 problem but it's a better packaging.

 Anyway I don't want to rely on #is: method because it conflates a lot of

 selectors into one.


 yes. it is. so what is the problem?


 The problem is that this #is: method is like aspirin: it makes the symptom
 disappear but it doesn't cure the disease (if there is one).


Why? It was proposed how to deal with too many is methods in Object class.
It is orthogonal to whether you should use isXXX pattern or not.
Because each case should be dealt separately (and that's where you
free to override #is: method
to serve your special purpose).

 Are you sure you understand the purpose of #is: method?


 No I didn't, but now that you revealed me the true purpose of #is:, I
 finally reached enlightenment.
 But apparently it's not the case of its own comment.

Despite the method's comment contains my name, it is not under my authorship.
Look for mailing list archives to see what i proposed then, and if it
different to what i saying now.

 A means for cleanly replacing all isXXX like methods.
 Please use judiciously!
 Suggested by Igor Stasenko at

 all isXXX should be converted following the pattern
 ColorFormisColorForm
 ^ true
 ObjectisColorForm
 ^ false
 is: aSymbol
 ^ aSymbol = #ColorForm or: [ super is: aSymbol ]

 its purpose is for cases when you realy realy very very badly want to
 add own isPlague to
 Object protocol. In that case, you should use 'is: #plague'
 because no new is methods should be added anymore.
 The feast is over, and you should use #is: method. (or think how to
 not use isXXX pattern at all).


 TL;DR: I agree with Camillo :)



 anyway, this topic has been discussed with enough hot air so far and no

 progress,


 which means it is absolutely not important. there are more urgent things to

 done...


i could not care less.. Back in 2009 i just proposed this.
Pharo people seems liked the idea and added this method into the image.
That's how my name appeared there.
And what i trying to (again as in 2009) articulate here, is how i see
to use this method.
But NOT whether it should stay in image or to be gone.



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Esteban Lorenzano]

I really cannot believe that you can consider 

is: #string

better programing than 

isString

no matter the implementation, and no matter if you can still found senders of 
#string... string programming (or symbol programing) is just bad, bad, bad. 
Is so bad that is axiomatic... I cannot even explain why... :)

and that just because we do not like to have 20 methods (or whatever the 
number) isBlah in object?

sorry, I completely disagree with the idea. 

now, I agree that some of the is methods should be removed, but that is a 
complete different discussion :)

Esteban 

On Jun 25, 2013, at 1:22 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 12:59, Camille Teruel camille.ter...@gmail.com wrote:
 
 On 25 juin 2013, at 11:45, Igor Stasenko wrote:
 
 On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote:
 
 
 On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
 
 
 
 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:
 
 
 
 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:
 
 
 
 the isBlah is not optimal now it is just there and we cannot rewrite
 
 everything.
 
 
 I still think that is: is a nice way to kill some of the isPlague in Object.
 
 
 
 I still don't see what you solve, and the idea to use symbols for #is: is
 
 also
 
 
 wrong, for me that's going back to string-based programming.
 
 
 
 well, that's basically my argument agains #is:
 
 IMO is also an important performance issue in many cases, because is
 
 replacing a simple send with a string comparison and that can provoke
 
 slowdowns in some places (no idea where,  this is just theoretical :)...
 
 Of course, as pharo designers we should be careful on not overpopulate
 
 Object with isBlah methods... but sometimes they are needed :)
 
 
 
 +1.
 
 Indeed, sometimes they are needed. You can't replace every isXXX send with a
 
 new visitor or dispatching by adding more and more extension methods all
 
 over the place (including Object BTW).
 
 Yet a fair amount of these methods can be removed.
 
 I think that a lot of these methods exist only because people think that
 
 isKindOf:/isMemberOf: are always evil, and its not true.
 
 There is at least three cases were I don't feel guilty using
 
 isKindOf:/isMemberOf: :
 
 - In unit tests
 
 - In #= methods
 
 - When I really want to ensure that an object is an instance of a specific
 
 class (see MethodContext#privRefreshWith: for example). This poor's man
 
 type checking can be replace with typed slots (that end up using
 
 isKindOf/isMemberOf: anyway).
 
 If we agree on that we can remove many #isXXX methods.
 
 Then there is some #isXXX methods that do not belong to Object (ex:
 
 #isTransferable belongs to Morph) and others that can be removed just by
 
 refactoring senders.
 
 We can also move some of them to extension methods, that doesn't solve the
 
 problem but it's a better packaging.
 
 Anyway I don't want to rely on #is: method because it conflates a lot of
 
 selectors into one.
 
 
 yes. it is. so what is the problem?
 
 
 The problem is that this #is: method is like aspirin: it makes the symptom
 disappear but it doesn't cure the disease (if there is one).
 
 
 Why? It was proposed how to deal with too many is methods in Object class.
 It is orthogonal to whether you should use isXXX pattern or not.
 Because each case should be dealt separately (and that's where you
 free to override #is: method
 to serve your special purpose).
 
 Are you sure you understand the purpose of #is: method?
 
 
 No I didn't, but now that you revealed me the true purpose of #is:, I
 finally reached enlightenment.
 But apparently it's not the case of its own comment.
 
 Despite the method's comment contains my name, it is not under my authorship.
 Look for mailing list archives to see what i proposed then, and if it
 different to what i saying now.
 
 A means for cleanly replacing all isXXX like methods.
 Please use judiciously!
 Suggested by Igor Stasenko at
 
 all isXXX should be converted following the pattern
 ColorFormisColorForm
 ^ true
 ObjectisColorForm
 ^ false
 is: aSymbol
 ^ aSymbol = #ColorForm or: [ super is: aSymbol ]
 
 its purpose is for cases when you realy realy very very badly want to
 add own isPlague to
 Object protocol. In that case, you should use 'is: #plague'
 because no new is methods should be added anymore.
 The feast is over, and you should use #is: method. (or think how to
 not use isXXX pattern at all).
 
 
 TL;DR: I agree with Camillo :)
 
 
 
 anyway, this topic has been discussed with enough hot air so far and no
 
 progress,
 
 
 which means it is absolutely not important. there are more urgent things to
 
 done...
 
 
 i could not care less.. Back in 2009 i just proposed this.
 Pharo people seems liked the idea and added this method into the image.
 That's how my name appeared there.
 And what i trying to (again as in 2009) articulate here, is how i see
 to use this method.
 But 

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote:
 I really cannot believe that you can consider

 is: #string

 better programing than

 isString

 no matter the implementation, and no matter if you can still found senders of 
 #string... string programming (or symbol programing) is just bad, bad, bad.
 Is so bad that is axiomatic... I cannot even explain why... :)


you are highly subjective here. :)

given two expressions:

object isString
and
object is: #string

to me they are equal in their beautiness or ugliness, if you like.


 and that just because we do not like to have 20 methods (or whatever the 
 number) isBlah in object?

 sorry, I completely disagree with the idea.

 now, I agree that some of the is methods should be removed, but that is a 
 complete different discussion :)

right. but that was the proposal to remove them first (by replacing with #is:)
and then gradually deal with them later (but already having cleaned
Object protocol).

 Esteban



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Esteban Lorenzano]

On Jun 25, 2013, at 1:36 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote:
 I really cannot believe that you can consider
 
 is: #string
 
 better programing than
 
 isString
 
 no matter the implementation, and no matter if you can still found senders 
 of #string... string programming (or symbol programing) is just bad, bad, 
 bad.
 Is so bad that is axiomatic... I cannot even explain why... :)
 
 
 you are highly subjective here. :)
 
 given two expressions:
 
 object isString
 and
 object is: #string
 
 to me they are equal in their beautiness or ugliness, if you like.

with the difference that in one: 

1) you has a clearer and more expressive message
2) you have a simple message send with an immediate return (and not a 
comparisson)

and in the other... you don't. 

but well, I already explained my opinion... and I think we are not going to 
agree. 
So I rest, I'm over of this :)

 
 
 and that just because we do not like to have 20 methods (or whatever the 
 number) isBlah in object?
 
 sorry, I completely disagree with the idea.
 
 now, I agree that some of the is methods should be removed, but that is a 
 complete different discussion :)
 
 right. but that was the proposal to remove them first (by replacing with #is:)
 and then gradually deal with them later (but already having cleaned
 Object protocol).
 
 Esteban
 
 
 
 -- 
 Best regards,
 Igor Stasenko.
 

Re: [Pharo-dev] Object #is:

[Henrik Johansen]

I agree with Esteban here, I think we just have to agree to disagree :)
To me as well, is: #Number reads 100x worse than isNumber.

On Jun 25, 2013, at 12:33 PM, Igor Stasenko wrote:
 
 In general, the more methods we put into Object, the higher
 probability of name clashing (two projects using same selector
 for method in Object but for different purpose).
 It also slows down the lookup time, because VM checks every method
 dictionary, including Object.
 (not speaking of slowing down UI ;)

Really? I thought this was one of the things PIC's are good at for where it 
matters, only recording cases for objects actually sent the message from a call 
site.
(Not that that's a big consolation for isMorph and other abuses of 
inheritance/polymorphism, but still...)

Cheers,
Henry

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 14:21, Henrik Johansen henrik.s.johan...@veloxit.no wrote:
 I agree with Esteban here, I think we just have to agree to disagree :)
 To me as well, is: #Number reads 100x worse than isNumber.

 On Jun 25, 2013, at 12:33 PM, Igor Stasenko wrote:


 In general, the more methods we put into Object, the higher
 probability of name clashing (two projects using same selector
 for method in Object but for different purpose).
 It also slows down the lookup time, because VM checks every method
 dictionary, including Object.
 (not speaking of slowing down UI ;)


 Really? I thought this was one of the things PIC's are good at for where it
 matters, only recording cases for objects actually sent the message from a
 call site.
 (Not that that's a big consolation for isMorph and other abuses of
 inheritance/polymorphism, but still...)


Sure, thing. But PICs are not permanent (and interpreter doesn't have
them). With cache you can avoid like 85%? of cases..
but for 15% VM still does lookup. And all caches tend to be flushed
periodically..
And then you pay the price of bloated method dictionary :)


 Cheers,
 Henry



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Camillo Bruni]

On 2013-06-25, at 14:35, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 14:00, Esteban Lorenzano esteba...@gmail.com wrote:
 
 On Jun 25, 2013, at 1:36 PM, Igor Stasenko siguc...@gmail.com wrote:
 
 On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote:
 I really cannot believe that you can consider
 
 is: #string
 
 better programing than
 
 isString
 
 no matter the implementation, and no matter if you can still found senders 
 of #string... string programming (or symbol programing) is just bad, bad, 
 bad.
 Is so bad that is axiomatic... I cannot even explain why... :)
 
 
 you are highly subjective here. :)
 
 given two expressions:
 
 object isString
 and
 object is: #string
 
 to me they are equal in their beautiness or ugliness, if you like.
 
 with the difference that in one:
 
 1) you has a clearer and more expressive message
 2) you have a simple message send with an immediate return (and not a 
 comparisson)
 
 and in the other... you don't.
 
 
 But that's exactly the point: if you so bad, that end up using is
 pattern in your code,
 you have to pay extra price for it!
 See, you don't like it! This is intentional! So, you should think how
 to avoid using it,
 and be forced to write better code :)
 
 Consider #is:, like anti-method for anti-pattern..
 but not as a very useful method.
 Then everything will fit on its place in your mind! :)


so that's why you install so many NativeBoost methods on Object??

invest your motivation into athens and txtext that is way more productive...

Re: [Pharo-dev] Object #is:

[Camille Teruel]

On 25 juin 2013, at 13:22, Igor Stasenko wrote:

 On 25 June 2013 12:59, Camille Teruel camille.ter...@gmail.com wrote:
 
 On 25 juin 2013, at 11:45, Igor Stasenko wrote:
 
 On 25 June 2013 11:09, Camille Teruel camille.ter...@gmail.com wrote:
 
 
 On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
 
 
 
 On Jun 24, 2013, at 6:59 PM, Camillo Bruni camillobr...@gmail.com wrote:
 
 
 
 On 2013-06-24, at 18:55, Stéphane Ducasse stephane.duca...@inria.fr wrote:
 
 
 
 the isBlah is not optimal now it is just there and we cannot rewrite
 
 everything.
 
 
 I still think that is: is a nice way to kill some of the isPlague in Object.
 
 
 
 I still don't see what you solve, and the idea to use symbols for #is: is
 
 also
 
 
 wrong, for me that's going back to string-based programming.
 
 
 
 well, that's basically my argument agains #is:
 
 IMO is also an important performance issue in many cases, because is
 
 replacing a simple send with a string comparison and that can provoke
 
 slowdowns in some places (no idea where,  this is just theoretical :)...
 
 Of course, as pharo designers we should be careful on not overpopulate
 
 Object with isBlah methods... but sometimes they are needed :)
 
 
 
 +1.
 
 Indeed, sometimes they are needed. You can't replace every isXXX send with a
 
 new visitor or dispatching by adding more and more extension methods all
 
 over the place (including Object BTW).
 
 Yet a fair amount of these methods can be removed.
 
 I think that a lot of these methods exist only because people think that
 
 isKindOf:/isMemberOf: are always evil, and its not true.
 
 There is at least three cases were I don't feel guilty using
 
 isKindOf:/isMemberOf: :
 
 - In unit tests
 
 - In #= methods
 
 - When I really want to ensure that an object is an instance of a specific
 
 class (see MethodContext#privRefreshWith: for example). This poor's man
 
 type checking can be replace with typed slots (that end up using
 
 isKindOf/isMemberOf: anyway).
 
 If we agree on that we can remove many #isXXX methods.
 
 Then there is some #isXXX methods that do not belong to Object (ex:
 
 #isTransferable belongs to Morph) and others that can be removed just by
 
 refactoring senders.
 
 We can also move some of them to extension methods, that doesn't solve the
 
 problem but it's a better packaging.
 
 Anyway I don't want to rely on #is: method because it conflates a lot of
 
 selectors into one.
 
 
 yes. it is. so what is the problem?
 
 
 The problem is that this #is: method is like aspirin: it makes the symptom
 disappear but it doesn't cure the disease (if there is one).
 
 
 Why? It was proposed how to deal with too many is methods in Object class.
 It is orthogonal to whether you should use isXXX pattern or not.
 Because each case should be dealt separately (and that's where you
 free to override #is: method
 to serve your special purpose).
 
 Are you sure you understand the purpose of #is: method?
 
 
 No I didn't, but now that you revealed me the true purpose of #is:, I
 finally reached enlightenment.
 But apparently it's not the case of its own comment.
 
 Despite the method's comment contains my name, it is not under my authorship.

I never said it was.

 Look for mailing list archives to see what i proposed then, and if it
 different to what i saying now.

I believe you. The link to the archive is dead BTW.

 
 A means for cleanly replacing all isXXX like methods.
 Please use judiciously!
 Suggested by Igor Stasenko at
 
 all isXXX should be converted following the pattern
 ColorFormisColorForm
 ^ true
 ObjectisColorForm
 ^ false
 is: aSymbol
 ^ aSymbol = #ColorForm or: [ super is: aSymbol ]
 
 its purpose is for cases when you realy realy very very badly want to
 add own isPlague to
 Object protocol. In that case, you should use 'is: #plague'
 because no new is methods should be added anymore.
 The feast is over, and you should use #is: method. (or think how to
 not use isXXX pattern at all).
 
 
 TL;DR: I agree with Camillo :)
 
 
 
 anyway, this topic has been discussed with enough hot air so far and no
 
 progress,
 
 
 which means it is absolutely not important. there are more urgent things to
 
 done...
 
 
 i could not care less.. Back in 2009 i just proposed this.
 Pharo people seems liked the idea and added this method into the image.
 That's how my name appeared there.
 And what i trying to (again as in 2009) articulate here, is how i see
 to use this method.
 But NOT whether it should stay in image or to be gone.
 
 
 
 -- 
 Best regards,
 Igor Stasenko.
 

Re: [Pharo-dev] Object #is:

[Igor Stasenko]

On 25 June 2013 14:54, Camillo Bruni camillobr...@gmail.com wrote:

 On 2013-06-25, at 14:35, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 14:00, Esteban Lorenzano esteba...@gmail.com wrote:

 On Jun 25, 2013, at 1:36 PM, Igor Stasenko siguc...@gmail.com wrote:

 On 25 June 2013 13:29, Esteban Lorenzano esteba...@gmail.com wrote:
 I really cannot believe that you can consider

 is: #string

 better programing than

 isString

 no matter the implementation, and no matter if you can still found 
 senders of #string... string programming (or symbol programing) is just 
 bad, bad, bad.
 Is so bad that is axiomatic... I cannot even explain why... :)


 you are highly subjective here. :)

 given two expressions:

 object isString
 and
 object is: #string

 to me they are equal in their beautiness or ugliness, if you like.

 with the difference that in one:

 1) you has a clearer and more expressive message
 2) you have a simple message send with an immediate return (and not a 
 comparisson)

 and in the other... you don't.


 But that's exactly the point: if you so bad, that end up using is
 pattern in your code,
 you have to pay extra price for it!
 See, you don't like it! This is intentional! So, you should think how
 to avoid using it,
 and be forced to write better code :)

 Consider #is:, like anti-method for anti-pattern..
 but not as a very useful method.
 Then everything will fit on its place in your mind! :)


 so that's why you install so many NativeBoost methods on Object??

 invest your motivation into athens and txtext that is way more productive...

i cannot, while [someone is wrong on the internet] :))
yeah.. i think this is enough.

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Nicolas Cellier]

Except that arithmetic on Fraction isExact, or should I say is: #exact,
while on Float is not, so definitely a Float is not a Fraction, even if its
internal representation is a Fraction.


2013/6/25 Igor Stasenko siguc...@gmail.com

 On 25 June 2013 13:34, Nicolas Cellier
 nicolas.cellier.aka.n...@gmail.com wrote:
  That does not answer my problem.
  2 both is: #fraction (with 1 denominator) and is: #integer so how do you
  implement?
  or: [super is: #number] ?
 

 i know you can give plenty of ideas how you would do it, like:

 #(foo bar baz) includes: yourQuery

 but i wouldn't recommend it :)


 Btw i find it really strange, why for Integer it answers true,
 but not for Floats

 i actually would expect that:

 10e50 isFraction
 0.5 isFraction
 should also answer true

 because the floating-point numbers, which we are using in computers,
 can be represented by a fraction.
 And only those, which cannot be represented by fraction (like Pi)
 should answer false.
 So, please, fix it, and then we will think how to better implement
 polymorphic check with single #is: method :)

 
  2013/6/25 Igor Stasenko siguc...@gmail.com
 
  On 25 June 2013 12:47, Nicolas Cellier
  nicolas.cellier.aka.n...@gmail.com wrote:
   But in some cases, you will end up with an object that is more than
 one
   thing:
   - a Number
   - an Integer
   - a Fraction
   For example 0 shall answer yes to these 3.
   So ^foo == #specialName just does not work, or you end up with caseOf:
  
 
  err, why?
 
  if you define it like:
 
  Numberis: symbol
^ symbol == #number
 
 
  0 is: #number = true
  0.0 is: #number = true
  0/1  is: #number = true
  ?
 
  It is actually up to implementor how to his own classes should process
  #is: message.
  The only invariant (which imo best one), that Object should always
  answer false to #is: message no matter what parameter you passed, to
  avoid any ambiguous cases and keep things simple and easy to remember.
  That means, that unless you override this method in own class, its
  instances will always answer false to #is: message.
  And when you override it, you are free to define it the way you like...
 
  MyClassis: foo
^ foo class == self class
  or
  MyClassis: foo
^ foo class name == self class name
  or
 
  MyClassis: foo
^ foo isKindOf: MyClass
 
  (no limits to imagination :)
 
  --
  Best regards,
  Igor Stasenko.
 
 



 --
 Best regards,
 Igor Stasenko.

Re: [Pharo-dev] Object #is:

[Henrik Johansen]

On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote:

 Just remove it :)
 
 Doru

Alternatively, start using it, and remove the rest of the is* methods on 
Object, which was the initial intent :P

Of course, there's a tradeoff between locality of implementation and 
discoverability with (default) tools here, in that you get less implementors, 
and Object is cleaner, but at the cost that finding the actual meaning of is: 
in use in a specific piece of code outside of a debugger *can* be a pain… 

In my mind, what's currently in use is the better tradeoff for day-to-day 
programming and maintenance . 

Extensions that don't require contrived protocol names for tool support would 
be a neat thing :)

Cheers,
Henry

Re: [Pharo-dev] Object #is:

[Esteban Lorenzano]

I never liked it, so I vote for removal :)

On Jun 24, 2013, at 11:27 AM, Henrik Johansen henrik.s.johan...@veloxit.no 
wrote:

 
 On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote:
 
 Just remove it :)
 
 Doru
 
 Alternatively, start using it, and remove the rest of the is* methods on 
 Object, which was the initial intent :P
 
 Of course, there's a tradeoff between locality of implementation and 
 discoverability with (default) tools here, in that you get less implementors, 
 and Object is cleaner, but at the cost that finding the actual meaning of is: 
 in use in a specific piece of code outside of a debugger *can* be a pain… 
 
 In my mind, what's currently in use is the better tradeoff for day-to-day 
 programming and maintenance . 
 
 Extensions that don't require contrived protocol names for tool support would 
 be a neat thing :)
 
 Cheers,
 Henry

Re: [Pharo-dev] Object #is:

[Stéphane Ducasse]

But I hate more isPlague in Object.

Stef

On Jun 24, 2013, at 12:55 PM, Esteban Lorenzano esteba...@gmail.com wrote:

 I never liked it, so I vote for removal :)
 
 On Jun 24, 2013, at 11:27 AM, Henrik Johansen henrik.s.johan...@veloxit.no 
 wrote:
 
 
 On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote:
 
 Just remove it :)
 
 Doru
 
 Alternatively, start using it, and remove the rest of the is* methods on 
 Object, which was the initial intent :P
 
 Of course, there's a tradeoff between locality of implementation and 
 discoverability with (default) tools here, in that you get less 
 implementors, and Object is cleaner, but at the cost that finding the actual 
 meaning of is: in use in a specific piece of code outside of a debugger 
 *can* be a pain… 
 
 In my mind, what's currently in use is the better tradeoff for day-to-day 
 programming and maintenance . 
 
 Extensions that don't require contrived protocol names for tool support 
 would be a neat thing :)
 
 Cheers,
 Henry
 
 

Re: [Pharo-dev] Object #is:

[Camillo Bruni]

On 2013-06-24, at 18:41, Stéphane Ducasse stephane.duca...@inria.fr wrote:

 But I hate more isPlague in Object.

I think that plage mostly arises when people do not like to use Visitors / 
DoubleDispatch.

Conceptually the #is: message IS exactly the same, instead of doing a dynamic 
dispatch
you write procedural code with if checks, no?

Re: [Pharo-dev] Object #is:

[Stéphane Ducasse]

the isBlah is not optimal now it is just there and we cannot rewrite 
everything. 
I still think that is: is a nice way to kill some of the isPlague in Object.

Stef

 But I hate more isPlague in Object.
 
 I think that plage mostly arises when people do not like to use Visitors / 
 DoubleDispatch.
 
 Conceptually the #is: message IS exactly the same, instead of doing a dynamic 
 dispatch
 you write procedural code with if checks, no?

Re: [Pharo-dev] Object #is:

[Sven Van Caekenberghe]

On 23 Jun 2013, at 18:14, Camillo Bruni camillobr...@gmail.com wrote:

 can we remove that, or is this still in use?

Hmm, no senders, no implementors, but the idea is not bad: it could replace a 
lot of methods. And it bears the signature of some illustrious hackers…

Sven

Re: [Pharo-dev] Object #is:

[Nicolas Cellier]

Except that if an object both is: this and is: that, from two different
packages, this will lead to an override.


2013/6/23 Sven Van Caekenberghe s...@stfx.eu


 On 23 Jun 2013, at 18:14, Camillo Bruni camillobr...@gmail.com wrote:

  can we remove that, or is this still in use?

 Hmm, no senders, no implementors, but the idea is not bad: it could
 replace a lot of methods. And it bears the signature of some illustrious
 hackers…

 Sven

Re: [Pharo-dev] Object #is:

[Camillo Bruni]

On 2013-06-23, at 19:19, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com 
wrote:

 Except that if an object both is: this and is: that, from two different
 packages, this will lead to an override.

from which package? #is: doesn't seem to be used in general

 2013/6/23 Sven Van Caekenberghe s...@stfx.eu
 
 
 On 23 Jun 2013, at 18:14, Camillo Bruni camillobr...@gmail.com wrote:
 
 can we remove that, or is this still in use?
 
 Hmm, no senders, no implementors, but the idea is not bad: it could
 replace a lot of methods. And it bears the signature of some illustrious
 hackers…
 
 Sven
 

Re: [Pharo-dev] Object #is:

[Tudor Girba]

Actually, a better implementation would be:

Objectis: aClassOrSymbol
 ^ aClassOrSymbol asString = self class name asString

Like this you can even pass the class instead of its name (I presume that
printOn: will not change any time soon so we can rely on the fact that we
can polymorphically obtain the name of the class via asString).

Cheers,
Doru



On Sun, Jun 23, 2013 at 9:30 PM, Camillo Bruni camillobr...@gmail.comwrote:


 On 2013-06-23, at 21:25, Tudor Girba tu...@tudorgirba.com wrote:

  If we want to have an Objectis:, why not:
 
  Objectis: aSymbol
  ^ aSymbol = self class name
 
  ?
 
  Like this, I do not have to override it unless I need to rely on a
  different mechanism.

 exactly, that is everybody's immediate reaction, except for the method's
 author ;)..




-- 
www.tudorgirba.com

Every thing has its own flow

Re: [Pharo-dev] Object#if:then:else:

[Hilaire Fernandes]

Le 18/06/2013 18:53, Camille Teruel a écrit :
 #someRandomObject if: then: else: thinking of doing a C style
 condition and not using at all the receiver.
 
 Come on, people are not that stupid ! 
 And if they really are, no matter what you do, they will write bad code
 eventually.


It is not a matter of stupidy but analogy as this is the way the brain
works. People with C knolwdge will make these mistakes, transposing
their C knowloedge to the Smalltak. I did that mistakes.

Hilaire


-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-dev] Object#if:then:else:

[Stéphane Ducasse]

is it not slower?
and I would remove as much as method as possible from Object.

why 
 | temp |
 temp := a long expression.
 temp aComplexTest
 ifTrue: [ temp something ]
 ifFalse: [ temp something else ].

is not good enough?

And finally we should kill as much as possible of these if…. so 


 Hello everyone.
 
 I see a lot of code that follows the following pattern:
 
 a long expression aComplexTest
 ifTrue: [ a long expression something ]
 ifFalse: [ a long expression something else ].
 
 The classic refactoring is to store a long expression in a temp to avoid 
 repetition:
 
 | temp |
 temp := a long expression.
 temp aComplexTest
 ifTrue: [ temp something ]
 ifFalse: [ temp something else ].
 
 Then  a long expression is evaluated once and the name of the temp can 
 carry a meaningful name that helps reading the code.
 But this is more verbose than the first version.
 But if you add the following method in Object:
 
 if: conditionBlock then: trueBlock else: falseBlock
 ^ (conditionBlock cull: self)
 ifTrue: [ trueBlock cull: value ]
 ifFalse: [ falseBlock cull: value ]
 
 You can then rewrite it like that:
 
 a long expression
 if: [ :obj | obj aComplexTest ]
 then: [ :obj | something ]
 else: [ :obj | something else ]
 
 The names of the block args can give a meaningful name depending on the 
 result of the test (something like ... if: #notEmpty then: [ :collection | 
 ... ] else: [ :emptyCollection | ... ]).  Using cull: for the three block 
 also enable a good flexibility: you can omit the arg when irrelevant.
 
 Likewise, we could also have Object#while:do:
 
 while: conditionBlock do: actionBlock
 ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ]
 
 What do you think?
 
 Camille

Re: [Pharo-dev] Object#if:then:else:

[Goubier Thierry]

Hi Camille,

It's not bad as things goes, because it does look a bit like 
non-smalltalk code (i.e. the if then else structure) except that the 
precise meaning is very much Smalltalk :


if: has a receiver, and there is a not so intuitive relationship between 
the bloc parameters and the receiver.


Honestly, as far as code reviews goes, I'll prefer the temp refactoring. 
Understandable without having to search for the implementors of 
#if:then:else:


Regards,

Thierry

Le 18/06/2013 10:51, Camille Teruel a écrit :

Hello everyone.

I see a lot of code that follows the following pattern:

a long expression aComplexTest
 ifTrue: [ a long expression something ]
 ifFalse: [ a long expression something else ].

The classic refactoring is to store a long expression in a temp to
avoid repetition:

| temp |
temp := a long expression.
temp aComplexTest
 ifTrue: [ temp something ]
 ifFalse: [ temp something else ].

Then a long expression is evaluated once and the name of the temp can
carry a meaningful name that helps reading the code.
But this is more verbose than the first version.
But if you add the following method in Object:

if: conditionBlock then: trueBlock else: falseBlock
 ^ (conditionBlock cull: self)
 ifTrue: [ trueBlock cull: value ]
 ifFalse: [ falseBlock cull: value ]

You can then rewrite it like that:

a long expression
 if: [ :obj | obj aComplexTest ]
 then: [ :obj | something ]
 else: [ :obj | something else ]

The names of the block args can give a meaningful name depending on the
result of the test (something like ... if: #notEmpty then: [ :collection
| ... ] else: [ :emptyCollection | ... ]).  Using cull: for the three
block also enable a good flexibility: you can omit the arg when irrelevant.

Likewise, we could also have Object#while:do:

while: conditionBlock do: actionBlock
 ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ]

What do you think?

Camille


--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] Object#if:then:else:

[Camille Teruel]

On 18 juin 2013, at 11:20, Goubier Thierry wrote:

 Hi Camille,
 
 It's not bad as things goes, because it does look a bit like non-smalltalk 
 code (i.e. the if then else structure) except that the precise meaning is 
 very much Smalltalk :

Ok the name may be confusing.
So if you rename it to something like #if:do:elseDo:, it would be more 
smalltalkish and there is no confusion with classical if-then-else. 

 if: has a receiver, and there is a not so intuitive relationship between the 
 bloc parameters and the receiver.

Talking to an arbitrary object is the goal, since booleans are not very 
talkative kind of object.
Compare 

| temp |
temp := complexExpression
temp isNil ifTrue: [...] ifFalse: [...  temp ...]

with:

complexExpression ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...]

ifNil:ifNotNil: is not better only because it is shorter, it is better because 
I am talking to the object I am auditing, not a stupid boolean that knows 
nothing else but its truth value.

 Honestly, as far as code reviews goes, I'll prefer the temp refactoring. 
 Understandable without having to search for the implementors of #if:then:else:


I know this would break a long time tradition and people may not like it, so 
that's a question of taste and style, not understandability. 
There would be only one implementor, the implementation is really simple and 
the selector is explicit. 
Anyone can get use to it in less than 2 min.
Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: ,... 
every time? 
No because people learned what they do when they learned Smalltalk, and I'm 
sure it didn't get them more than a few minutes.

 
 Regards,
 
 Thierry
 
 Le 18/06/2013 10:51, Camille Teruel a écrit :
 Hello everyone.
 
 I see a lot of code that follows the following pattern:
 
 a long expression aComplexTest
 ifTrue: [ a long expression something ]
 ifFalse: [ a long expression something else ].
 
 The classic refactoring is to store a long expression in a temp to
 avoid repetition:
 
 | temp |
 temp := a long expression.
 temp aComplexTest
 ifTrue: [ temp something ]
 ifFalse: [ temp something else ].
 
 Then a long expression is evaluated once and the name of the temp can
 carry a meaningful name that helps reading the code.
 But this is more verbose than the first version.
 But if you add the following method in Object:
 
 if: conditionBlock then: trueBlock else: falseBlock
 ^ (conditionBlock cull: self)
 ifTrue: [ trueBlock cull: value ]
 ifFalse: [ falseBlock cull: value ]
 
 You can then rewrite it like that:
 
 a long expression
 if: [ :obj | obj aComplexTest ]
 then: [ :obj | something ]
 else: [ :obj | something else ]
 
 The names of the block args can give a meaningful name depending on the
 result of the test (something like ... if: #notEmpty then: [ :collection
 | ... ] else: [ :emptyCollection | ... ]).  Using cull: for the three
 block also enable a good flexibility: you can omit the arg when irrelevant.
 
 Likewise, we could also have Object#while:do:
 
 while: conditionBlock do: actionBlock
 ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ]
 
 What do you think?
 
 Camille
 
 -- 
 Thierry Goubier
 CEA list
 Laboratoire des Fondations des Systèmes Temps Réel Embarqués
 91191 Gif sur Yvette Cedex
 France
 Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
 

Re: [Pharo-dev] Object#if:then:else:

[Goubier Thierry]

Le 18/06/2013 12:27, Camille Teruel a écrit :


On 18 juin 2013, at 11:20, Goubier Thierry wrote:


Hi Camille,

It's not bad as things goes, because it does look a bit like
non-smalltalk code (i.e. the if then else structure) except that the
precise meaning is very much Smalltalk :


Ok the name may be confusing.
So if you rename it to something like #if:do:elseDo:, it would be more
smalltalkish and there is no confusion with classical if-then-else.


Maybe, that would help.


if: has a receiver, and there is a not so intuitive relationship
between the bloc parameters and the receiver.


Talking to an arbitrary object is the goal, since booleans are not very
talkative kind of object.
Compare

| temp |
temp := complexExpression
temp isNil ifTrue: [...] ifFalse: [...  temp ...]

with:

complexExpression ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...]

ifNil:ifNotNil: is not better only because it is shorter, it is better
because I am talking to the object I am auditing, not a stupid boolean
that knows nothing else but its truth value.


Yes, but I know firsthand (because I used Smalltalk before that idiom 
was introduced) that it represent one more idiom to learn, and it's 
still not familiar.


The same goes with withStreamDo: or what is that idiom again I sometimes 
encounter.



Honestly, as far as code reviews goes, I'll prefer the temp
refactoring. Understandable without having to search for the
implementors of #if:then:else:


I know this would break a long time tradition and people may not like
it, so that's a question of taste and style, not understandability.
There would be only one implementor, the implementation is really simple
and the selector is explicit.



Anyone can get use to it in less than 2 min.


It's one more thing to get used to and to explain to beginners in say 10 
minutes per idiom... (describe, give an example, let them practice, 
rinse and repeat for each idiom).


Add all the new idioms and, instead of explaining Smalltalk in half a 
day, you spend a few days doing explaining all those idioms and not 
doing more interesting stuff.


Soon, you end up like ocaml, where your minimum introduction time is a 
week, not half a day.



Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse:
,... every time?



No because people learned what they do when they learned Smalltalk, and
I'm sure it didn't get them more than a few minutes.


Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, 
your variant of if-else, and, and ... On some of those, I have to look 
for the implementors, and I'm really happy to benefit from the smart 
suggestions in the new browsers. (Additionally, code patterns using 
cull: in pharo more often than not are very poorly documented about the 
arguments that are given to the block).


Smalltalk is disruptive enough as it is (and still is after all those 
years) to try not to make it more complex. I'd prefer efforts making 
obvious really complex patterns instead of idioms with a not so great 
cognitive load to effectiveness.


I'd be happy to have a shorter list of methods and extensions on Object, 
as well :)


Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] Object#if:then:else:

[Otto Behrens]

It feels to me as if this code wants to be on the temp. So perhaps,

 | temp |
 temp := a long expression.
 temp aComplexTest
 ifTrue: [ temp something ]
 ifFalse: [ temp something else ].

can become

a long expression doSomething

and on Temp:

doSomething
   self aComplexTest
 ifTrue: [ self something ]
 ifFalse: [ self something else ]

It often works out nicer if you move the code around closer to where
it belongs. Make a long expression a method somewhere and it may end
up being simpler.

my2c

Re: [Pharo-dev] Object#if:then:else:

[kilon]

ifEvaluatesToTrueUsing sounds like an overkill to me and unnecessary , its
common convention in all popular languages than an if always needs to
evaluate to true to execute and if it evaluates to false then else handles
it.  



--
View this message in context: 
http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693945.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Object#if:then:else:

[kilon]

Very few things are truly necessary in life, programming languages are not
amongst them. 

As I said , for me how already things work in pharo is fine concerning
ifTrue: and friends . 



--
View this message in context: 
http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693952.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Object#if:then:else:

[Clément Bera]

I don't like this new structure. Then people coming from non object
language using all the time control structure will do :

#someRandomObject if: then: else: thinking of doing a C style condition and
not using at all the receiver.

I like how it is now.


2013/6/18 kilon theki...@yahoo.co.uk

 Very few things are truly necessary in life, programming languages are not
 amongst them.

 As I said , for me how already things work in pharo is fine concerning
 ifTrue: and friends .



 --
 View this message in context:
 http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693952.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.




-- 
Clément Béra
Mate Virtual Machine Engineer
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*

Re: [Pharo-dev] Object#if:then:else:

[Camille Teruel]

On 18 juin 2013, at 17:04, Clément Bera wrote:

 I don't like this new structure. Then people coming from non object language 
 using all the time control structure will do :
 
 #someRandomObject if: then: else: thinking of doing a C style condition and 
 not using at all the receiver.

Come on, people are not that stupid ! 
And if they really are, no matter what you do, they will write bad code 
eventually.

 I like how it is now.

It is not about replacing stuff, just adding one method. ifTrue:ifFalse: is 
still the better choice in most situations.

 
 2013/6/18 kilon theki...@yahoo.co.uk
 Very few things are truly necessary in life, programming languages are not
 amongst them.
 
 As I said , for me how already things work in pharo is fine concerning
 ifTrue: and friends .
 
 
 
 --
 View this message in context: 
 http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693952.html
 Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
 
 
 
 
 -- 
 Clément Béra
 Mate Virtual Machine Engineer
 Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq