On 30 August 2011 19:34, Lukas Renggli <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>> On 30 August 2011 18:02, Douglas Brebner <[email protected]>
>>> 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
>
>
