Symbol>value:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Symbol>value:

niko.schwarz
Hi,

Symbol responds to #value:, but not to #value:value:.

At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:

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

Of course, it should also respond to #value:value:value: and #value:value:value:value:

Niko

--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41786126354


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Tudor Girba-2
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.

From this point of view, they have similar responsibilities and we should be able to treat them the same.

Cheers,
Doru


On 30 Aug 2011, at 14:12, [hidden email] wrote:

> Hi,
>
> Symbol responds to #value:, but not to #value:value:.
>
> At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:
>
> value: anObject value: anotherObject
> ^ anObject perform: self with: anotherObject
>
> Of course, it should also respond to #value:value:value: and #value:value:value:value:
>
> Niko
>
> --
> http://scg.unibe.ch/staff/Schwarz
> twitter.com/nes1983
> Tel: +41786126354
>
>

--
www.tudorgirba.com

"Speaking louder won't make the point worthier."


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

niko.schwarz
I think it's important to have a consistent answer to the question:
"Can you treat symbols as blocks?".

Niko

On Tue, Aug 30, 2011 at 2:30 PM, Tudor Girba <[hidden email]> 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.
>
> From this point of view, they have similar responsibilities and we should be able to treat them the same.
>
> Cheers,
> Doru
>
>
> On 30 Aug 2011, at 14:12, [hidden email] wrote:
>
>> Hi,
>>
>> Symbol responds to #value:, but not to #value:value:.
>>
>> At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:
>>
>> value: anObject value: anotherObject
>>       ^ anObject perform: self with: anotherObject
>>
>> Of course, it should also respond to #value:value:value: and #value:value:value:value:
>>
>> Niko
>>
>> --
>> http://scg.unibe.ch/staff/Schwarz
>> twitter.com/nes1983
>> Tel: +41786126354
>>
>>
>
> --
> www.tudorgirba.com
>
> "Speaking louder won't make the point worthier."
>
>
>



--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41786126354

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Sven Van Caekenberghe
In reply to this post by Tudor Girba-2

On 30 Aug 2011, at 14:30, Tudor Girba wrote:

> 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.
>
> From this point of view, they have similar responsibilities and we should be able to treat them the same.

It feels as if this is only the case when the first argument is also the receiver, no ?

| adder |
adder := [ :x :y | x + y ].
adder value: 1 value: 2.

#+ value: 1 value: 2

1 perform: #+ with: 2

Note that the last two expressions are equally short/concise, the second being clearer.

Here things become weirder, don't you agree:

| creator |
creator := [ :x :y | Rectangle origin: 0@0 corner: x@ y ].
creator value: 10 value: 20.

#origin:corner: value: Rectangle value: 0@0 value: 10@20

Rectangle perform: #origin:corner: with: 0@0 with: 10@20

Maybe we need more good example of where this would make real sense ?

Sven


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

niko.schwarz
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <[hidden email]> wrote:

> #+ value: 1 value: 2
>
> 1 perform: #+ with: 2
>
> Note that the last two expressions are equally short/concise, the second being clearer.

That is not a comparison worth making. The fair comparison is:

[:a :b  | a + b]

vs

#+

Now, I'd say, the second is clearer. With it, Pharo gains support for
Tacit programming [1].

Niko



[1] http://en.wikipedia.org/wiki/Tacit_programming

--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41786126354

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Damien Cassou
In reply to this post by Sven Van Caekenberghe
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <[hidden email]> wrote:
> Maybe we need more good example of where this would make real sense ?

persons select: [:p | p isAdult]
persons select: #isAdult

persons inject: OrderedCollection new into: [:col :p | col copyWith: p]
persons inject: OrderedCollection new into: #copyWith:



--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

niko.schwarz
> persons inject: OrderedCollection new into: [:col :p | col copyWith: p]
> persons inject: OrderedCollection new into: #copyWith:

Or this one:

#(3 2 1) asSortedCollection: [:a :b | a <= b]
#(3 2 1) asSortedCollection: #<=

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Sven Van Caekenberghe
In reply to this post by Damien Cassou

On 30 Aug 2011, at 16:16, Damien Cassou wrote:

> On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>> Maybe we need more good example of where this would make real sense ?
>
> persons select: [:p | p isAdult]
> persons select: #isAdult

Yes, I am already writing that a lot.

> persons inject: OrderedCollection new into: [:col :p | col copyWith: p]
> persons inject: OrderedCollection new into: #copyWith:

#(1 2 3) inject: 0 into: #+

OK, I am sold ;-)

Sven
Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

HwaJong Oh
In reply to this post by niko.schwarz
I have similar definitions from symbol to block for SortedCollection like;

#('3' '20' '100') asSortedCollection: #size ascendingSortBlock. "#('3' '20' '100')"

#size ascendingSortBlock evaluates to be [:a :b| (a perform: #size) <= (b perform:#size) ]

#('3' '20' '100') asSortedCollection: #size descendingSortBlock. "#('100' '20' '3')"


Similarly, following can be done

#('3' '20' '100') asSortedCollection: #first ascendingSortBlock.
#('3' '20' '100') asSortedCollection: #first descendingSortBlock.
Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Douglas Brebner
In reply to this post by Tudor Girba-2
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.

Also, some of the examples in this thread seem to be about terseness for terseness sake.

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

niko.schwarz
In reply to this post by HwaJong Oh
You just inspired me to a block post on point-free programming :)

http://smalltalkthoughts.blogspot.com/2011/08/point-free-programming-in-smalltalk.html

Niko



On 30.08.2011, at 16:57, HwaJong Oh wrote:

> I have similar definitions from symbol to block for SortedCollection like;
>
> #('3' '20' '100') asSortedCollection: #size ascendingSortBlock. "#('3' '20'
> '100')"
>
> #size ascendingSortBlock evaluates to be [:a :b| (a perform: #size) <= (b
> perform:#size) ]
>
> #('3' '20' '100') asSortedCollection: #size descendingSortBlock. "#('100'
> '20' '3')"
>
>
> Similarly, following can be done
>
> #('3' '20' '100') asSortedCollection: #first ascendingSortBlock.
> #('3' '20' '100') asSortedCollection: #first descendingSortBlock.
>
> --
> View this message in context: http://forum.world.st/Symbol-value-tp3778525p3778943.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41786126354


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Igor Stasenko
In reply to this post by Douglas Brebner
On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

niko.schwarz
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 <[hidden email]> wrote:

> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Nicolas Cellier
Same question with cull:

2011/8/30 Niko Schwarz <[hidden email]>:

> 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 <[hidden email]> wrote:
>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Lukas Renggli
In reply to this post by niko.schwarz
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.

Lukas

On 30 August 2011 20:09, Niko Schwarz <[hidden email]> 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 <[hidden email]> wrote:
>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Stéphane Ducasse
In reply to this post by niko.schwarz
makes sense.

http://code.google.com/p/pharo/issues/detail?id=4726

Stef

On Aug 30, 2011, at 2:12 PM, [hidden email] wrote:

> Hi,
>
> Symbol responds to #value:, but not to #value:value:.
>
> At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:
>
> value: anObject value: anotherObject
> ^ anObject perform: self with: anotherObject
>
> Of course, it should also respond to #value:value:value: and #value:value:value:value:
>
> Niko
>
> --
> http://scg.unibe.ch/staff/Schwarz
> twitter.com/nes1983
> Tel: +41786126354
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Frank Shearar-3
In reply to this post by Lukas Renggli
On 30 August 2011 19:34, Lukas Renggli <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Stéphane Ducasse
In reply to this post by Douglas Brebner

On Aug 30, 2011, at 6:02 PM, Douglas Brebner 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.

It was just a stupid idea of mine :)

>
> Also, some of the examples in this thread seem to be about terseness for terseness sake.
>


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Stéphane Ducasse
In reply to this post by Lukas Renggli
Indeed I would prefer just to have perform: and block value:

Stef

On Aug 30, 2011, at 8:34 PM, Lukas Renggli 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.
>
> Lukas
>
> On 30 August 2011 20:09, Niko Schwarz <[hidden email]> 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 <[hidden email]> wrote:
>>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Symbol>value:

Stéphane Ducasse
My suggestion is the following one:
        we could add it because there is value: now I would not use it in the core of the system.
        I hope that one of these days we will be able to bootstrap and identify a kernel and after that
        we could tag a bit the methods in terms of layers.

Stef

On Aug 30, 2011, at 9:14 PM, Stéphane Ducasse wrote:

> Indeed I would prefer just to have perform: and block value:
>
> Stef
>
> On Aug 30, 2011, at 8:34 PM, Lukas Renggli 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.
>>
>> Lukas
>>
>> On 30 August 2011 20:09, Niko Schwarz <[hidden email]> 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 <[hidden email]> wrote:
>>>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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
>>
>
>


12