On 30 August 2011 19:34, Lukas Renggli <renggli@gmail.com> wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Like all strong flavours, it's very useful/tasty in small doses. I'm not sure that #inject:into value: #(1 2 3) value: 0 value: #+ is particularly useful. Having said that, I did find it useful playing around with partial continuations to define #compose: on the continuations, symbols and blocks. It made for very readable (IMO at least :) ) code. ZipperControl class >> zipOver: aCollection | f zippers | f := [:a | [:k | Zipper on: a with: (k compose: [:x | x maybe: #yourself default: a])] shift]. ^ [ZipDone on: (aCollection collect: [:each | f value: each])] reset. compared to the original Haskell: make_zipper :: T.Traversable t => t a -> Zipper t a make_zipper t = reset $ T.mapM f t >>= return . ZDone where f a = shift (\k -> return $ Z a (k . maybe a id)) (From http://okmij.org/ftp/continuations/zipper.html#traversable) frank
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch