Issue 4726 in pharo: Symbol>>value: anObject value: anotherObject

Status: Accepted
Owner: [hidden email]
Labels: Milestone-1.4

New issue 4726 by [hidden email]: Symbol>>value: anObject value:  
anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

value: anObject value: anotherObject
        ^ anObject perform: self with: anotherObject


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixToInclude

Comment #1 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #2 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

If we add this on Symbol then it should also be added to CompiledMethod IMO.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #3 on issue 4726 by renggli: Symbol>>value: anObject value:  
anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

As a last try, let me report some leaking abstractions that will be  
introduced with this change:

     #(1 2 3) reduce: [ :a :b | a + b ]   ---> 6
     #(1 2 3) reduce: #+   ---> Error

     #(1 2 3) groupsOf: 2 atATimeCollect: [ :a :b | a + b ]  ---> 3
     #(1 2 3) groupsOf: 2 atATimeCollect: #+  ---> Error




_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

here some more details

so the first example fails due to missing Symbol >> #valueWithArguments:  
and Symbol >> #argumentCount
the second example due to buggy String >> numArgs

so unless these things are added and changed as well the #value:value: is  
not of much use.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 4726 by renggli: Symbol>>value: anObject value:  
anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

Note that #numArgs and #argumentCount are not buggy, they both return the  
correct number if the symbol is used as a method selector (#foo has 0  
arguments, #foo: has 1 argument, ...). A lot of the existing system code  
depends on that (120+ senders). With the proposed change the same method  
should suddenly also count the receiver as an argument (the above examples  
would work if #foo returned 1, #foo: returned 2, ...). This is a leaking  
abstraction.

Check the blog of Vassili Bykov, he proposed a nice and much more powerful  
infrastructure that has none of these drawbacks. Readability is still  
questionable though:

- Selectors as Blocks:  
http://blog.3plus4.org/2007/03/27/selectors-as-blocks/
- Sections: http://blog.3plus4.org/2007/03/31/sections/
- Sections Wrap-Up: http://blog.3plus4.org/2007/04/06/sections-wrap-up/


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

right, I was confused :D it wouldn't make much sense to count the receiver  
as an argument...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

So now I'm confused. It looks like this changes introduce more problems  
that it solved.

#(1 2 3) reduce: #+

I do not get why this is not working compared to the block use.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #8 on issue 4726 by renggli: Symbol>>value: anObject value:  
anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

#reduce: (and many other methods) ask their "block" for the number of  
arguments. As a method #+ has one argument (in fact, 1 receiver and 1  
argument), however if it is used in a block context it suddenly should have  
two arguments (#value:value: only works on two argument blocks).


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #9 on issue 4726 by renggli: Symbol>>value: anObject value:  
anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

Note that we have the same absurdity with Symbol>>#value:

- Symbol>>#value: only works on 0 argument selectors (does not make sense)
- Block>>#value: only works on 1 argument blocks (makes sense)

Read the 3 posts of Vassili, he explains the problems and possible  
solutions very nicely. To summarize: Vassili writes that you must wrap the  
symbol (a name) in an object. Like this you can encapsulate the selector in  
an object that has none of these problems. In fact there are already  
various such implementations in Pharo, search for MessageSend and friends.  
Vassili describes a slightly more generic variation that also deals with  
argument permutations and stuff ...



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #10 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

Thanks for the info. I will read vassili blog. So to me it means that this  
is not worth the pain.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Comment

Comment #11 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: WontFix

Comment #12 on issue 4726 by [hidden email]: Symbol>>value: anObject  
value: anotherObject
http://code.google.com/p/pharo/issues/detail?id=4726

So we don't add this?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker