On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni@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
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 <sven@stfx.eu>
On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni@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
On 2013-06-23, at 19:19, Nicolas Cellier <nicolas.cellier.aka.nice@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 <sven@stfx.eu>
On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni@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
If we want to have an Object>>is:, why not: Object>>is: aSymbol ^ aSymbol = self class name ? Like this, I do not have to override it unless I need to rely on a different mechanism. Cheers, Doru On Sun, Jun 23, 2013 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2013-06-23, at 19:19, Nicolas Cellier < nicolas.cellier.aka.nice@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 <sven@stfx.eu>
On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni@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
-- www.tudorgirba.com "Every thing has its own flow"
On 2013-06-23, at 21:25, Tudor Girba <tudor@tudorgirba.com> wrote:
If we want to have an Object>>is:, why not:
Object>>is: 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 ;)..
Actually, a better implementation would be: Object>>is: 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 <camillobruni@gmail.com>wrote:
On 2013-06-23, at 21:25, Tudor Girba <tudor@tudorgirba.com> wrote:
If we want to have an Object>>is:, why not:
Object>>is: 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"
On 2013-06-23, at 21:40, Tudor Girba <tudor@tudorgirba.com> wrote:
Actually, a better implementation would be:
Object>>is: 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).
... and we're starting from scratch again, sorry, I spent too much time discussing this already :P => I am very much against comparing strings, this just doesn't scale
Just remove it :) Doru On Sun, Jun 23, 2013 at 9:44 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2013-06-23, at 21:40, Tudor Girba <tudor@tudorgirba.com> wrote:
Actually, a better implementation would be:
Object>>is: 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).
... and we're starting from scratch again, sorry, I spent too much time discussing this already :P
=> I am very much against comparing strings, this just doesn't scale
-- www.tudorgirba.com "Every thing has its own flow"
On Jun 23, 2013, at 10:08 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Just remove it :)
I do not really like to have extra symbol not directly connected to their classes. I understand the idea behind is: but â¦.
Doru
On Sun, Jun 23, 2013 at 9:44 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-23, at 21:40, Tudor Girba <tudor@tudorgirba.com> wrote:
Actually, a better implementation would be:
Object>>is: 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).
... and we're starting from scratch again, sorry, I spent too much time discussing this already :P
=> I am very much against comparing strings, this just doesn't scale
-- www.tudorgirba.com
"Every thing has its own flow"
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
I never liked it, so I vote for removal :) On Jun 24, 2013, at 11:27 AM, Henrik Johansen <henrik.s.johansen@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
But I hate more isPlague in Object. Stef On Jun 24, 2013, at 12:55 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I never liked it, so I vote for removal :)
On Jun 24, 2013, at 11:27 AM, Henrik Johansen <henrik.s.johansen@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
On 2013-06-24, at 18:41, Stéphane Ducasse <stephane.ducasse@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?
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?
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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. 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...
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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.
Not only :)
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 agree
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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...
On 25 June 2013 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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 :)
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.
On Jun 25, 2013, at 10:47 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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?
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.
On 25 June 2013 10:51, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 25, 2013, at 10:47 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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.
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 :)
Yes those are the ones I was talking about. I would like to understand how we can remove them. Stef
On Jun 25, 2013, at 10:54 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 10:51, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 25, 2013, at 10:47 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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.
On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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.
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...
On 25 June 2013 11:09, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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 isXXXX 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.
On 25 juin 2013, at 11:45, Igor Stasenko wrote:
On 25 June 2013 11:09, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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).
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. "A means for cleanly replacing all isXXX like methods. Please use judiciously! Suggested by Igor Stasenko at http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html. all isXXX should be converted following the pattern ColorForm>>isColorForm ^ true Object>>isColorForm ^ 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 isXXXX 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.
On 25 June 2013 12:59, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 11:45, Igor Stasenko wrote:
On 25 June 2013 11:09, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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 isXXXX 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 ColorForm>>isColorForm ^ true Object>>isColorForm ^ 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 isXXXX 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.
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 <siguctua@gmail.com> wrote:
On 25 June 2013 12:59, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 11:45, Igor Stasenko wrote:
On 25 June 2013 11:09, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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 isXXXX 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 ColorForm>>isColorForm ^ true Object>>isColorForm ^ 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 isXXXX 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.
On 25 June 2013 13:29, Esteban Lorenzano <estebanlm@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.
On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 13:29, Esteban Lorenzano <estebanlm@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.
On 25 June 2013 14:00, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 13:29, Esteban Lorenzano <estebanlm@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 isXXXX 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! :)
but well, I already explained my opinion... and I think we are not going to agree. So I rest, I'm over of this :)
-- Best regards, Igor Stasenko.
On 2013-06-25, at 14:35, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 14:00, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 13:29, Esteban Lorenzano <estebanlm@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 isXXXX 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...
On 25 June 2013 14:54, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-25, at 14:35, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 14:00, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 June 2013 13:29, Esteban Lorenzano <estebanlm@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 isXXXX 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.
On 25 juin 2013, at 13:22, Igor Stasenko wrote:
On 25 June 2013 12:59, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 11:45, Igor Stasenko wrote:
On 25 June 2013 11:09, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2013, at 10:28, Esteban Lorenzano wrote:
On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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 isXXXX 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 ColorForm>>isColorForm ^ true Object>>isColorForm ^ 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 isXXXX 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.
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 <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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
On 25 June 2013 11:54, Henrik Johansen <henrik.s.johansen@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 <camillobruni@gmail.com> wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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. Object>>is: foo ^ false MyClass>>is: 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.
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 <siguctua@gmail.com>
On 25 June 2013 11:54, Henrik Johansen <henrik.s.johansen@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 <camillobruni@gmail.com>
wrote:
On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.ducasse@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. Object>>is: foo ^ false
MyClass>>is: 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.
On 25 June 2013 12:47, Nicolas Cellier <nicolas.cellier.aka.nice@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: Number>>is: 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... MyClass>>is: foo ^ foo class == self class or MyClass>>is: foo ^ foo class name == self class name or MyClass>>is: foo ^ foo isKindOf: MyClass (no limits to imagination :) -- Best regards, Igor Stasenko.
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] ? 2013/6/25 Igor Stasenko <siguctua@gmail.com>
On 25 June 2013 12:47, Nicolas Cellier <nicolas.cellier.aka.nice@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:
Number>>is: 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...
MyClass>>is: foo ^ foo class == self class or MyClass>>is: foo ^ foo class name == self class name or
MyClass>>is: foo ^ foo isKindOf: MyClass
(no limits to imagination :)
-- Best regards, Igor Stasenko.
On 25 June 2013 13:34, Nicolas Cellier <nicolas.cellier.aka.nice@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 <siguctua@gmail.com>
On 25 June 2013 12:47, Nicolas Cellier <nicolas.cellier.aka.nice@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:
Number>>is: 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...
MyClass>>is: foo ^ foo class == self class or MyClass>>is: foo ^ foo class name == self class name or
MyClass>>is: foo ^ foo isKindOf: MyClass
(no limits to imagination :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
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 <siguctua@gmail.com>
On 25 June 2013 13:34, Nicolas Cellier <nicolas.cellier.aka.nice@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 <siguctua@gmail.com>
On 25 June 2013 12:47, Nicolas Cellier <nicolas.cellier.aka.nice@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:
Number>>is: 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...
MyClass>>is: foo ^ foo class == self class or MyClass>>is: foo ^ foo class name == self class name or
MyClass>>is: foo ^ foo isKindOf: MyClass
(no limits to imagination :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
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
On 25 June 2013 14:21, Henrik Johansen <henrik.s.johansen@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.
participants (9)
-
Camille Teruel -
Camillo Bruni -
Esteban Lorenzano -
Henrik Johansen -
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba