funny idea Symbol vs. Selector

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

funny idea Symbol vs. Selector

stephane ducasse
Hi guys

I'm thinking aloud...
I was wondering if we could not take advantage of a new class: Selector.
MethodDict would only contain selectors and not symbols.

I remember that I talked about that with hernan.

Stef


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Igor Stasenko
On 23 August 2010 23:26, stephane ducasse <[hidden email]> wrote:
> Hi guys
>
> I'm thinking aloud...
> I was wondering if we could not take advantage of a new class: Selector.
> MethodDict would only contain selectors and not symbols.
>
> I remember that I talked about that with hernan.
>

Hmm.. i don't see obvious advantages. Do you?
Most symbols (90% of cases), used as selectors, so it is likely that
such refactoring will be nothing more,
but just renaming the class :)

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Stéphane Ducasse
we often use symbols for identity keys.
Now I was just dreaming.

>> Hi guys
>>
>> I'm thinking aloud...
>> I was wondering if we could not take advantage of a new class: Selector.
>> MethodDict would only contain selectors and not symbols.
>>
>> I remember that I talked about that with hernan.
>>
>
> Hmm.. i don't see obvious advantages. Do you?
> Most symbols (90% of cases), used as selectors, so it is likely that
> such refactoring will be nothing more,
> but just renaming the class :)
>
>> Stef
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Igor Stasenko
On 24 August 2010 16:16, Stéphane Ducasse <[hidden email]> wrote:
> we often use symbols for identity keys.
> Now I was just dreaming.
>
I had a long discussion with my friend, who was learning smalltalk,
where we argued about 'selector is not a symbol'.

The difference between a bare string and symbol is uniqueness.
Literally, a symbol is just a string, which having additional, implied
semantics, that
same symbolic strings refer to a single, unique object. (Another minor
one is immutability).

The difference between a symbol and selector is less significant.
A simple example. Suppose you have two different classes, one Symbol,
other is Selector.
Now, suppose that compiler creating an instance of Symbol each time it
sees following:

self foo.

where 'foo' is selector (and instance of Selector).

but now, lets put it in another way:

self perform: #foo.

A #foo is, obviously a symbol, and must be an instance of Symbol class, isnt?

So, in #perform: you must somehow convert a symbol into selector and
then find the implementation
of method with given selector.
This obviously kills an idea of having distinction between selectors
and symbols, because implementation
of #perform: will be awfully slow and awkward.

>>> Hi guys
>>>
>>> I'm thinking aloud...
>>> I was wondering if we could not take advantage of a new class: Selector.
>>> MethodDict would only contain selectors and not symbols.
>>>
>>> I remember that I talked about that with hernan.
>>>
>>
>> Hmm.. i don't see obvious advantages. Do you?
>> Most symbols (90% of cases), used as selectors, so it is likely that
>> such refactoring will be nothing more,
>> but just renaming the class :)
>>
>>> Stef
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Stéphane Ducasse
that a fun one.

BTW I know that david simmons introduced == and === on symbol
and === was checking the namespace in which the symbol was defined and this way he implemented selector namespace.

On Aug 24, 2010, at 4:00 PM, Igor Stasenko wrote:

> On 24 August 2010 16:16, Stéphane Ducasse <[hidden email]> wrote:
>> we often use symbols for identity keys.
>> Now I was just dreaming.
>>
> I had a long discussion with my friend, who was learning smalltalk,
> where we argued about 'selector is not a symbol'.
>
> The difference between a bare string and symbol is uniqueness.
> Literally, a symbol is just a string, which having additional, implied
> semantics, that
> same symbolic strings refer to a single, unique object. (Another minor
> one is immutability).
>
> The difference between a symbol and selector is less significant.
> A simple example. Suppose you have two different classes, one Symbol,
> other is Selector.
> Now, suppose that compiler creating an instance of Symbol each time it
> sees following:
>
> self foo.
>
> where 'foo' is selector (and instance of Selector).
>
> but now, lets put it in another way:
>
> self perform: #foo.
>
> A #foo is, obviously a symbol, and must be an instance of Symbol class, isnt?
>
> So, in #perform: you must somehow convert a symbol into selector and
> then find the implementation
> of method with given selector.
> This obviously kills an idea of having distinction between selectors
> and symbols, because implementation
> of #perform: will be awfully slow and awkward.
>
>>>> Hi guys
>>>>
>>>> I'm thinking aloud...
>>>> I was wondering if we could not take advantage of a new class: Selector.
>>>> MethodDict would only contain selectors and not symbols.
>>>>
>>>> I remember that I talked about that with hernan.
>>>>
>>>
>>> Hmm.. i don't see obvious advantages. Do you?
>>> Most symbols (90% of cases), used as selectors, so it is likely that
>>> such refactoring will be nothing more,
>>> but just renaming the class :)
>>>
>>>> Stef
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-users mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

hernanmd
In reply to this post by stephane ducasse
It always strikes me why some concepts are thought and included as
innate (like Time) and others not (like Space). This is the same for
Reference and Meaning. This is the part when the human takes part of
the system, try to infer the use of the following undocumented method

>>doSomething
       ^ #beActive

you cannot tell if it is intended to use as an selector or not, even
Active doesn't tell us anything about the reference (active? who?
self?) or the meaning (active a state right? which one?).

Looking at both classes:

Symbol doesn't carry a meaning (because it is used as a Sign)
Selector does carry a meaning (because it is used as Significantum)
and Smalltalk serves as the mediator between the naming and its usage.

Looking at the instances

aSymbol includes a name, could be meaningless, possibly without a
reference, say #ewrewrjew (or we may not recognize if actually have a
reference)
aSelector includes a name plus an idea, probably with a reference
(which is its the raison d'être).

You could "solve" the impractical problem of modeling the roles just
using new names: Create a class Sign which could be used as Name or
Selector or both. Having a Selector class only serves (to me, and now
:) if one wants to ask things like

#name senders (exception, name is not used as sender)
#name implementors (idem)
...
#selector senders (answer a list of references where selector is used as sender)
#selector implementors (idem as implementors)
#selector events (idem for named events)
#selector isSender ...

and get the answers faster than the tools today.
But the last case is a proof (why not Event class?) that the same way
we may model universals... so it's really a question of efficency and
usefullness, that's one of the reasons why humans are included in the
system, we cannot dream of modelling everything.
Cheers,

Hernán

2010/8/23 stephane ducasse <[hidden email]>:

> Hi guys
>
> I'm thinking aloud...
> I was wondering if we could not take advantage of a new class: Selector.
> MethodDict would only contain selectors and not symbols.
>
> I remember that I talked about that with hernan.
>
> Stef
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Stéphane Ducasse
In reply to this post by stephane ducasse
I;m sorry that I raised a stupid idea.
Don;t bash people for me :)

On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:

> Hi guys
>
> I'm thinking aloud...
> I was wondering if we could not take advantage of a new class: Selector.
> MethodDict would only contain selectors and not symbols.
>
> I remember that I talked about that with hernan.
>
> Stef
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

hernanmd
Actually I think is one of the better ideas I've read in this list.
Too bad nobody seems interested in semiotics :(

2010/8/25 Stéphane Ducasse <[hidden email]>:

> I;m sorry that I raised a stupid idea.
> Don;t bash people for me :)
>
> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>
>> Hi guys
>>
>> I'm thinking aloud...
>> I was wondering if we could not take advantage of a new class: Selector.
>> MethodDict would only contain selectors and not symbols.
>>
>> I remember that I talked about that with hernan.
>>
>> Stef
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Stéphane Ducasse
:)

Your previous mail was what the bee I had in my bonnet :)

Stef

On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:

> Actually I think is one of the better ideas I've read in this list.
> Too bad nobody seems interested in semiotics :(
>
> 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> I;m sorry that I raised a stupid idea.
>> Don;t bash people for me :)
>>
>> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>>
>>> Hi guys
>>>
>>> I'm thinking aloud...
>>> I was wondering if we could not take advantage of a new class: Selector.
>>> MethodDict would only contain selectors and not symbols.
>>>
>>> I remember that I talked about that with hernan.
>>>
>>> Stef
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Hernan Wilkinson-3
From the design point of view, I like the idea, a selector is not a symbol and we can see that clearly in the Symbol protocol, like Mariano and Gabriel said, implements messages that are related to selector behavior... Why symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors responsibilities... not all symbols are selectors... so for me, it is a good idea. 
This idea brings implementation challenges of course, but nothing new :-)

On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse <[hidden email]> wrote:
:)

Your previous mail was what the bee I had in my bonnet :)

Stef

On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:

> Actually I think is one of the better ideas I've read in this list.
> Too bad nobody seems interested in semiotics :(
>
> 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> I;m sorry that I raised a stupid idea.
>> Don;t bash people for me :)
>>
>> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>>
>>> Hi guys
>>>
>>> I'm thinking aloud...
>>> I was wondering if we could not take advantage of a new class: Selector.
>>> MethodDict would only contain selectors and not symbols.
>>>
>>> I remember that I talked about that with hernan.
>>>
>>> Stef
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


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



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Marcin Tustin
But then eliminating those methods introduces a circularity problem: What if a symbol starts to be used as a selector part of the way through the life of that object? It's not a fixed property of a symbol to be, or not be, a selector.

On Wed, Aug 25, 2010 at 7:11 PM, Hernan Wilkinson <[hidden email]> wrote:
From the design point of view, I like the idea, a selector is not a symbol and we can see that clearly in the Symbol protocol, like Mariano and Gabriel said, implements messages that are related to selector behavior... Why symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors responsibilities... not all symbols are selectors... so for me, it is a good idea. 
This idea brings implementation challenges of course, but nothing new :-)

On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse <[hidden email]> wrote:
:)

Your previous mail was what the bee I had in my bonnet :)

Stef

On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:

> Actually I think is one of the better ideas I've read in this list.
> Too bad nobody seems interested in semiotics :(
>
> 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> I;m sorry that I raised a stupid idea.
>> Don;t bash people for me :)
>>
>> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>>
>>> Hi guys
>>>
>>> I'm thinking aloud...
>>> I was wondering if we could not take advantage of a new class: Selector.
>>> MethodDict would only contain selectors and not symbols.
>>>
>>> I remember that I talked about that with hernan.
>>>
>>> Stef
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


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



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


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




--
Marcin Tustin
Mobile: 07773787105
Office: 020 3400 3259

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Hernan Wilkinson-3
Could you give me an example?

On Wed, Aug 25, 2010 at 3:16 PM, Marcin Tustin <[hidden email]> wrote:
But then eliminating those methods introduces a circularity problem: What if a symbol starts to be used as a selector part of the way through the life of that object? It's not a fixed property of a symbol to be, or not be, a selector.


On Wed, Aug 25, 2010 at 7:11 PM, Hernan Wilkinson <[hidden email]> wrote:
From the design point of view, I like the idea, a selector is not a symbol and we can see that clearly in the Symbol protocol, like Mariano and Gabriel said, implements messages that are related to selector behavior... Why symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors responsibilities... not all symbols are selectors... so for me, it is a good idea. 
This idea brings implementation challenges of course, but nothing new :-)

On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse <[hidden email]> wrote:
:)

Your previous mail was what the bee I had in my bonnet :)

Stef

On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:

> Actually I think is one of the better ideas I've read in this list.
> Too bad nobody seems interested in semiotics :(
>
> 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> I;m sorry that I raised a stupid idea.
>> Don;t bash people for me :)
>>
>> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>>
>>> Hi guys
>>>
>>> I'm thinking aloud...
>>> I was wondering if we could not take advantage of a new class: Selector.
>>> MethodDict would only contain selectors and not symbols.
>>>
>>> I remember that I talked about that with hernan.
>>>
>>> Stef
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


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



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


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




--
Marcin Tustin
Mobile: 07773787105
Office: 020 3400 3259

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




--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Igor Stasenko
In reply to this post by Hernan Wilkinson-3
On 25 August 2010 21:11, Hernan Wilkinson <[hidden email]> wrote:
> From the design point of view, I like the idea, a selector is not a symbol
> and we can see that clearly in the Symbol protocol, like Mariano and Gabriel
> said, implements messages that are related to selector behavior... Why
> symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors
> responsibilities... not all symbols are selectors... so for me, it is a good
> idea.

not all symbols are selectors...
but you never tell, that they could not be, once you load new package
or write more code.

I see the need of having a separate subclass for Symbol , instead of
stopping at String,
because it have to maintain uniqueness and immutability.

String + uniqueness + immutability => Symbol

so, there is a strong reason for having a separate class for it, but

Symbol + ??? => Selector

give me a strong reason.

i like the idea of shrinking a Symbol's protocol and putting it into
lean and clean place - Symbol.
But this is not strong enough.
In practice, such shrinking, could lead to explosion of complexity in
many other places.


'foo' = #foo  ->true
#foo = 'foo' -> true

#foo asSelector = #foo ??

if so, then
#foo hash = #foo asSelector hash ?

and , obviously
#foo == #foo asSelector  => false

which means, that mixing selectors and symbols in a single collection
will be very bad idea,
and source of bugs and confusion.
But what gives us a uniqueness of symbols is, that we don't need to
use #= for comparing them,
but #== , which is much faster. Right?

Now, if you introduce selectors, there is no uniqueness anymore, since
selector is a symbol (since it is a subclass of it), and must honor
the rules of its ancestor..
but its not.
The only way how to deal with that is to make particular symbol
(sub)instance to be either
an instance of Symbol or Selector but not both.
This means that in system you could have either
#foo
or
#foo asSelector
but not both, otherwise you will violate the uniqueness rule.

Objects could play many roles, depending on their use. Just take a
look at Object protocol, and answer yourself, how
many of these methods is userful in some specific case (such as an
object used to identify a message - selector).
So, if you want to dissect all roles onto a set of specific
(sub)classes, i propose to start from an Object class,
and then, gradually get to a Symbol.

> This idea brings implementation challenges of course, but nothing new :-)
> On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>>
>> :)
>>
>> Your previous mail was what the bee I had in my bonnet :)
>>
>> Stef
>>
>> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>>
>> > Actually I think is one of the better ideas I've read in this list.
>> > Too bad nobody seems interested in semiotics :(
>> >
>> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> >> I;m sorry that I raised a stupid idea.
>> >> Don;t bash people for me :)
>> >>
>> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>> >>
>> >>> Hi guys
>> >>>
>> >>> I'm thinking aloud...
>> >>> I was wondering if we could not take advantage of a new class:
>> >>> Selector.
>> >>> MethodDict would only contain selectors and not symbols.
>> >>>
>> >>> I remember that I talked about that with hernan.
>> >>>
>> >>> Stef
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Pharo-users mailing list
>> >>> [hidden email]
>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >>
>> >>
>> >> _______________________________________________
>> >> Pharo-users mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >>
>> >
>> > _______________________________________________
>> > Pharo-users mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Igor Stasenko
On 25 August 2010 22:33, Igor Stasenko <[hidden email]> wrote:

> On 25 August 2010 21:11, Hernan Wilkinson <[hidden email]> wrote:
>> From the design point of view, I like the idea, a selector is not a symbol
>> and we can see that clearly in the Symbol protocol, like Mariano and Gabriel
>> said, implements messages that are related to selector behavior... Why
>> symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors
>> responsibilities... not all symbols are selectors... so for me, it is a good
>> idea.
>
> not all symbols are selectors...
> but you never tell, that they could not be, once you load new package
> or write more code.
>
> I see the need of having a separate subclass for Symbol , instead of
> stopping at String,
> because it have to maintain uniqueness and immutability.
>
> String + uniqueness + immutability => Symbol
>
> so, there is a strong reason for having a separate class for it, but
>
> Symbol + ??? => Selector
>
> give me a strong reason.
>
> i like the idea of shrinking a Symbol's protocol and putting it into
> lean and clean place - Symbol.

oops, clean place is obviously Selector here.

> But this is not strong enough.
> In practice, such shrinking, could lead to explosion of complexity in
> many other places.
>
>
> 'foo' = #foo  ->true
> #foo = 'foo' -> true
>
> #foo asSelector = #foo ??
>
> if so, then
> #foo hash = #foo asSelector hash ?
>
> and , obviously
> #foo == #foo asSelector  => false
>
> which means, that mixing selectors and symbols in a single collection
> will be very bad idea,
> and source of bugs and confusion.
> But what gives us a uniqueness of symbols is, that we don't need to
> use #= for comparing them,
> but #== , which is much faster. Right?
>
> Now, if you introduce selectors, there is no uniqueness anymore, since
> selector is a symbol (since it is a subclass of it), and must honor
> the rules of its ancestor..
> but its not.
> The only way how to deal with that is to make particular symbol
> (sub)instance to be either
> an instance of Symbol or Selector but not both.
> This means that in system you could have either
> #foo
> or
> #foo asSelector
> but not both, otherwise you will violate the uniqueness rule.
>
> Objects could play many roles, depending on their use. Just take a
> look at Object protocol, and answer yourself, how
> many of these methods is userful in some specific case (such as an
> object used to identify a message - selector).
> So, if you want to dissect all roles onto a set of specific
> (sub)classes, i propose to start from an Object class,
> and then, gradually get to a Symbol.
>
>> This idea brings implementation challenges of course, but nothing new :-)
>> On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>>
>>> :)
>>>
>>> Your previous mail was what the bee I had in my bonnet :)
>>>
>>> Stef
>>>
>>> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>>>
>>> > Actually I think is one of the better ideas I've read in this list.
>>> > Too bad nobody seems interested in semiotics :(
>>> >
>>> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>>> >> I;m sorry that I raised a stupid idea.
>>> >> Don;t bash people for me :)
>>> >>
>>> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>>> >>
>>> >>> Hi guys
>>> >>>
>>> >>> I'm thinking aloud...
>>> >>> I was wondering if we could not take advantage of a new class:
>>> >>> Selector.
>>> >>> MethodDict would only contain selectors and not symbols.
>>> >>>
>>> >>> I remember that I talked about that with hernan.
>>> >>>
>>> >>> Stef
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Pharo-users mailing list
>>> >>> [hidden email]
>>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Pharo-users mailing list
>>> >> [hidden email]
>>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>> >>
>>> >
>>> > _______________________________________________
>>> > Pharo-users mailing list
>>> > [hidden email]
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>>
>> --
>> Hernán Wilkinson
>> Agile Software Development, Teaching & Coaching
>> Mobile: +54 - 11 - 4470 - 7207
>> email: [hidden email]
>> site: http://www.10Pines.com
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Hernan Wilkinson-3
In reply to this post by Igor Stasenko


On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <[hidden email]> wrote:
On 25 August 2010 21:11, Hernan Wilkinson <[hidden email]> wrote:
> From the design point of view, I like the idea, a selector is not a symbol
> and we can see that clearly in the Symbol protocol, like Mariano and Gabriel
> said, implements messages that are related to selector behavior... Why
> symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors
> responsibilities... not all symbols are selectors... so for me, it is a good
> idea.

not all symbols are selectors...
but you never tell, that they could not be, once you load new package
or write more code.

I see the need of having a separate subclass for Symbol , instead of
stopping at String,
because it have to maintain uniqueness and immutability.

String + uniqueness + immutability => Symbol

so, there is a strong reason for having a separate class for it, but

Symbol + ??? => Selector

give me a strong reason.

meaning, semantic... that I thing are stronger reasons that uniqueness for example, because uniqueness is an implementation issue, meaning is not. Immutability is not an implementation issue is part of the semantic of the object.
 

i like the idea of shrinking a Symbol's protocol and putting it into
lean and clean place - Symbol.
But this is not strong enough.
In practice, such shrinking, could lead to explosion of complexity in
many other places.


'foo' = #foo  ->true
#foo = 'foo' -> true

#foo asSelector = #foo ??

clearly no, we are saying that a symbol should be different from a selector, therefore they should never be equal no matter if their "printable" representation is the same (as in this example #foo)


if so, then
#foo hash = #foo asSelector hash ?

could or could not... depends on the implementation, who cares?
 

and , obviously
#foo == #foo asSelector  => false

yes, and #foo = #foo asSelector --> false
 

which means, that mixing selectors and symbols in a single collection
will be very bad idea,
and source of bugs and confusion.

why?  
It is not the same the relationship between a symbol and a string that with a symbol and a selector.
We could say that a symbol and a string represent a sequence of characters, so if they represent the same sequence of characters they have to be equal, that is why #foo = 'foo', (that means 'foo' asUniqueString = 'foo' where asUniqueString is the real meaning of the # in front of the symbols...), but a selector does not represent a sequence of character, it represents the name of a message. Therefore for me a selector has a "name" that is a symbol, but a selector IS NOT a symbol, because can answer messages like numOfArgs:, sendTo: etc.

But what gives us a uniqueness of symbols is, that we don't need to
use #= for comparing them,
but #== , which is much faster. Right?

well, I think that using #== is a wrong design decision, for me you should only use #== if you are dealing with "memory" issues, if you really want two objects to be in the same memory position, therefore it is an implementation issue, but no if you are designing for extensibility....
 

Now, if you introduce selectors, there is no uniqueness anymore,

why?
 
since
selector is a symbol (since it is a subclass of it),

why? I would not make it a subclass... using a subclass only to reuse code it is a bad design decision from my point of view, Selector should be a class by itself whose instances know a name, that are instances of Symbol

and must honor
the rules of its ancestor..
but its not.
The only way how to deal with that is to make particular symbol
(sub)instance to be either
an instance of Symbol or Selector but not both.
This means that in system you could have either
#foo
or
#foo asSelector
but not both, otherwise you will violate the uniqueness rule.

the problem you see is, as I said above, because you are subclassing symbol which is not what I would do.
 

Objects could play many roles, depending on their use. Just take a
look at Object protocol, and answer yourself, how
many of these methods is userful in some specific case (such as an
object used to identify a message - selector).
So, if you want to dissect all roles onto a set of specific
(sub)classes, i propose to start from an Object class,
and then, gradually get to a Symbol.

Not a bad idea!! Object is completely out of control and we should remove a lot of the methods it has! I completely agree there :-)

 

> This idea brings implementation challenges of course, but nothing new :-)
> On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>>
>> :)
>>
>> Your previous mail was what the bee I had in my bonnet :)
>>
>> Stef
>>
>> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>>
>> > Actually I think is one of the better ideas I've read in this list.
>> > Too bad nobody seems interested in semiotics :(
>> >
>> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> >> I;m sorry that I raised a stupid idea.
>> >> Don;t bash people for me :)
>> >>
>> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>> >>
>> >>> Hi guys
>> >>>
>> >>> I'm thinking aloud...
>> >>> I was wondering if we could not take advantage of a new class:
>> >>> Selector.
>> >>> MethodDict would only contain selectors and not symbols.
>> >>>
>> >>> I remember that I talked about that with hernan.
>> >>>
>> >>> Stef
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Pharo-users mailing list
>> >>> [hidden email]
>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >>
>> >>
>> >> _______________________________________________
>> >> Pharo-users mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >>
>> >
>> > _______________________________________________
>> > Pharo-users mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Igor Stasenko
On 25 August 2010 23:08, Hernan Wilkinson <[hidden email]> wrote:

>
>
> On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 25 August 2010 21:11, Hernan Wilkinson <[hidden email]>
>> wrote:
>> > From the design point of view, I like the idea, a selector is not a
>> > symbol
>> > and we can see that clearly in the Symbol protocol, like Mariano and
>> > Gabriel
>> > said, implements messages that are related to selector behavior... Why
>> > symbols respond to numArgs:, precedence, isUnary, etc? those are a
>> > selectors
>> > responsibilities... not all symbols are selectors... so for me, it is a
>> > good
>> > idea.
>>
>> not all symbols are selectors...
>> but you never tell, that they could not be, once you load new package
>> or write more code.
>>
>> I see the need of having a separate subclass for Symbol , instead of
>> stopping at String,
>> because it have to maintain uniqueness and immutability.
>>
>> String + uniqueness + immutability => Symbol
>>
>> so, there is a strong reason for having a separate class for it, but
>>
>> Symbol + ??? => Selector
>>
>> give me a strong reason.
>
> meaning, semantic... that I thing are stronger reasons that uniqueness for
> example, because uniqueness is an implementation issue, meaning is not.
> Immutability is not an implementation issue is part of the semantic of the
> object.
>

Meaning could be anything. It depends from context where i using this object.
From machine's point of view there is no meaning, only semantic.

So, i am asking, what _technical_ benefits it would brings us.
Because from meaning point of view, a symbol #foo reads foo,
as well as selector foo, and only we (humans) know that it is selector
in one context,
or just a simple 'unique string' in another one.

>>
>> i like the idea of shrinking a Symbol's protocol and putting it into
>> lean and clean place - Symbol.
>> But this is not strong enough.
>> In practice, such shrinking, could lead to explosion of complexity in
>> many other places.
>>
>>
>> 'foo' = #foo  ->true
>> #foo = 'foo' -> true
>>
>> #foo asSelector = #foo ??
>
> clearly no, we are saying that a symbol should be different from a selector,
> therefore they should never be equal no matter if their
> "printable" representation is the same (as in this example #foo)
>>
>> if so, then
>> #foo hash = #foo asSelector hash ?
>
> could or could not... depends on the implementation, who cares?
>
>>
>> and , obviously
>> #foo == #foo asSelector  => false
>
> yes, and #foo = #foo asSelector --> false
>
>>
>> which means, that mixing selectors and symbols in a single collection
>> will be very bad idea,
>> and source of bugs and confusion.
>
> why?
> It is not the same the relationship between a symbol and a string that with
> a symbol and a selector.
> We could say that a symbol and a string represent a sequence of characters,
> so if they represent the same sequence of characters they have to be equal,
> that is why #foo = 'foo', (that means 'foo' asUniqueString = 'foo' where
> asUniqueString is the real meaning of the # in front of the symbols...), but
> a selector does not represent a sequence of character, it represents the
> name of a message. Therefore for me a selector has a "name" that is a
> symbol, but a selector IS NOT a symbol, because can answer messages like
> numOfArgs:, sendTo: etc.

it could have a sense to use different entity, when you would need to
hold additional state.
I can imagine a class, like 'measure unit', with two variables - value
and units.
So, you can express 1 cm, 1 mm, 1 km, 100 kg using such object.
But in case of selectors , you expressing a symbol, and there is no
need for additional state.

>>
>> But what gives us a uniqueness of symbols is, that we don't need to
>> use #= for comparing them,
>> but #== , which is much faster. Right?
>
> well, I think that using #== is a wrong design decision, for me you should
> only use #== if you are dealing with "memory" issues, if you really want two
> objects to be in the same memory position, therefore it is an implementation
> issue, but no if you are designing for extensibility....
>
>>
>> Now, if you introduce selectors, there is no uniqueness anymore,
>
> why?
>

well, because two things which having same name should be equal.
Otherwise it makes no sense to use same name for them.
Keep in mind, that symbols are made for humans. Machine feels pretty well with
pointers and don't needs to know anything about names.

>>
>> since
>> selector is a symbol (since it is a subclass of it),
>
> why? I would not make it a subclass... using a subclass only to reuse code
> it is a bad design decision from my point of view, Selector should be a
> class by itself whose instances know a name, that are instances of Symbol
>>
>> and must honor
>> the rules of its ancestor..
>> but its not.
>> The only way how to deal with that is to make particular symbol
>> (sub)instance to be either
>> an instance of Symbol or Selector but not both.
>> This means that in system you could have either
>> #foo
>> or
>> #foo asSelector
>> but not both, otherwise you will violate the uniqueness rule.
>
> the problem you see is, as I said above, because you are subclassing symbol
> which is not what I would do.
>

So, you want a completely separate class for selectors,
which by sending #name (for instance) will answer a symbol which
identifies them?
I see, use delegation instead of inheritance.

But then, technically, this means that for each symbol, which used as
selector, you will need to add
an additional instance of Selector, which wraps around symbol.
Sounds not very good.
But maybe there are benefits, which outweights such memory increase?
Tell me more.

It reminds me a MethodReference.
It also identifies a CompiledMethod, without referring directly to
class or method.
But if you look closer at its implementation, you'll see that it is
used as a dumb state holder,
grouping different aspects of a method's state.
It is used extensively by browser tools, even in places, where you
could use and talk with compiled methods directly.
Needless to say, that i can't understand such approach: why one would
need to wrap things with a proxy,
only to access the state of an object of interest though it? Why an
object of interest can't give same answers directly?

I would understand that tools could be made so, that they can work
with real objects as well as with proxies,
which both honoring same protocol.
But blindly wrapping each object with proxy?? This is beyond my
understanding abilities.

>>
>> Objects could play many roles, depending on their use. Just take a
>> look at Object protocol, and answer yourself, how
>> many of these methods is userful in some specific case (such as an
>> object used to identify a message - selector).
>> So, if you want to dissect all roles onto a set of specific
>> (sub)classes, i propose to start from an Object class,
>> and then, gradually get to a Symbol.
>
> Not a bad idea!! Object is completely out of control and we should remove a
> lot of the methods it has! I completely agree there :-)
>
Hehe. Good luck with that :)
Sure thing, i'd like to see less methods in Object class.

>>
>> > This idea brings implementation challenges of course, but nothing new
>> > :-)
>> > On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
>> > <[hidden email]> wrote:
>> >>
>> >> :)
>> >>
>> >> Your previous mail was what the bee I had in my bonnet :)
>> >>
>> >> Stef
>> >>
>> >> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>> >>
>> >> > Actually I think is one of the better ideas I've read in this list.
>> >> > Too bad nobody seems interested in semiotics :(
>> >> >
>> >> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> >> >> I;m sorry that I raised a stupid idea.
>> >> >> Don;t bash people for me :)
>> >> >>
>> >> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>> >> >>
>> >> >>> Hi guys
>> >> >>>
>> >> >>> I'm thinking aloud...
>> >> >>> I was wondering if we could not take advantage of a new class:
>> >> >>> Selector.
>> >> >>> MethodDict would only contain selectors and not symbols.
>> >> >>>
>> >> >>> I remember that I talked about that with hernan.
>> >> >>>
>> >> >>> Stef
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Pharo-users mailing list
>> >> >>> [hidden email]
>> >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Pharo-users mailing list
>> >> >> [hidden email]
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-users mailing list
>> >> > [hidden email]
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >>
>> >>
>> >> _______________________________________________
>> >> Pharo-users mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>> >
>> > --
>> > Hernán Wilkinson
>> > Agile Software Development, Teaching & Coaching
>> > Mobile: +54 - 11 - 4470 - 7207
>> > email: [hidden email]
>> > site: http://www.10Pines.com
>> >
>> > _______________________________________________
>> > Pharo-users mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Hernan Wilkinson-3


On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <[hidden email]> wrote:
On 25 August 2010 23:08, Hernan Wilkinson <[hidden email]> wrote:
>
>
> On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 25 August 2010 21:11, Hernan Wilkinson <[hidden email]>
>> wrote:
>> > From the design point of view, I like the idea, a selector is not a
>> > symbol
>> > and we can see that clearly in the Symbol protocol, like Mariano and
>> > Gabriel
>> > said, implements messages that are related to selector behavior... Why
>> > symbols respond to numArgs:, precedence, isUnary, etc? those are a
>> > selectors
>> > responsibilities... not all symbols are selectors... so for me, it is a
>> > good
>> > idea.
>>
>> not all symbols are selectors...
>> but you never tell, that they could not be, once you load new package
>> or write more code.
>>
>> I see the need of having a separate subclass for Symbol , instead of
>> stopping at String,
>> because it have to maintain uniqueness and immutability.
>>
>> String + uniqueness + immutability => Symbol
>>
>> so, there is a strong reason for having a separate class for it, but
>>
>> Symbol + ??? => Selector
>>
>> give me a strong reason.
>
> meaning, semantic... that I thing are stronger reasons that uniqueness for
> example, because uniqueness is an implementation issue, meaning is not.
> Immutability is not an implementation issue is part of the semantic of the
> object.
>

Meaning could be anything. It depends from context where i using this object.

hmmm, for me the meaning of an object is given by the messages it knows how to respond, no context related. I'm talking about objects defined in a formal language, not of entities described in natural language where context influences meaning... 
 
From machine's point of view there is no meaning, only semantic.

hehe, I thought that machines only treated symbols, therefore they are incapable to provide semantic to them... only we human can provide meaning (that for me is the same as semantic in this context :-) ), so we have basic differences in fundamental concepts... I don't think we will agree therefore on high level ones...


So, i am asking, what _technical_ benefits it would brings us.

I don't care about technical benefits, I care about modeling benefits. I leave the technical issues to the computer that does not get tired when doing things over and over again... :-).
Asking only for technical benefits of a solution is like asking why do we have garbage collection? what is the technical benefit of it? it takes more time that manually deleting objects, it needs more memory, etc. so what is its technical benefit? none... the benefit is for us, because it allow us to delegate the memory management responsibility to the computer (a repetitive process) and free our mind to concentrate on important issues
 

Because from meaning point of view, a symbol #foo reads foo,
as well as selector foo, and only we (humans) know that it is selector
in one context,
or just a simple 'unique string' in another one.

>>
>> i like the idea of shrinking a Symbol's protocol and putting it into
>> lean and clean place - Symbol.
>> But this is not strong enough.
>> In practice, such shrinking, could lead to explosion of complexity in
>> many other places.
>>
>>
>> 'foo' = #foo  ->true
>> #foo = 'foo' -> true
>>
>> #foo asSelector = #foo ??
>
> clearly no, we are saying that a symbol should be different from a selector,
> therefore they should never be equal no matter if their
> "printable" representation is the same (as in this example #foo)
>>
>> if so, then
>> #foo hash = #foo asSelector hash ?
>
> could or could not... depends on the implementation, who cares?
>
>>
>> and , obviously
>> #foo == #foo asSelector  => false
>
> yes, and #foo = #foo asSelector --> false
>
>>
>> which means, that mixing selectors and symbols in a single collection
>> will be very bad idea,
>> and source of bugs and confusion.
>
> why?
> It is not the same the relationship between a symbol and a string that with
> a symbol and a selector.
> We could say that a symbol and a string represent a sequence of characters,
> so if they represent the same sequence of characters they have to be equal,
> that is why #foo = 'foo', (that means 'foo' asUniqueString = 'foo' where
> asUniqueString is the real meaning of the # in front of the symbols...), but
> a selector does not represent a sequence of character, it represents the
> name of a message. Therefore for me a selector has a "name" that is a
> symbol, but a selector IS NOT a symbol, because can answer messages like
> numOfArgs:, sendTo: etc.

it could have a sense to use different entity, when you would need to
hold additional state.
I can imagine a class, like 'measure unit', with two variables - value
and units.
So, you can express 1 cm, 1 mm, 1 km, 100 kg using such object.
But in case of selectors , you expressing a symbol, and there is no
need for additional state.

Different objects are not only created because they have different "state" but because they have different responsibilities, for me that is the central issue, and as I said before I see that we do not agree on fundamental issues so...
  

>>
>> But what gives us a uniqueness of symbols is, that we don't need to
>> use #= for comparing them,
>> but #== , which is much faster. Right?
>
> well, I think that using #== is a wrong design decision, for me you should
> only use #== if you are dealing with "memory" issues, if you really want two
> objects to be in the same memory position, therefore it is an implementation
> issue, but no if you are designing for extensibility....
>
>>
>> Now, if you introduce selectors, there is no uniqueness anymore,
>
> why?
>

well, because two things which having same name should be equal.
Otherwise it makes no sense to use same name for them.
Keep in mind, that symbols are made for humans. Machine feels pretty well with
pointers and don't needs to know anything about names.

but programs are made by humans, read by humans and maintain by humans, so that is why we have symbol instead of pointers and true instead of 1 and false instead of 0... for us, not for the machine.
I don't understand why you say that there will be no more uniqueness, a selector can be unique per its name or not, that is an implementation issue, that is, how much memory you want to consume... the important thing is that selectors with the same name should be equal, who cares if they share the same memory position? only the implementor of the vm... I don't care if "Date today == Date today", I do care that "Date today = Date today"... if tomorrow the Date implementor decides to do "Date today == Date today", good, that is an implementation issue, could be good could be bad, and I as a user of Date should not care.


>>
>> since
>> selector is a symbol (since it is a subclass of it),
>
> why? I would not make it a subclass... using a subclass only to reuse code
> it is a bad design decision from my point of view, Selector should be a
> class by itself whose instances know a name, that are instances of Symbol
>>
>> and must honor
>> the rules of its ancestor..
>> but its not.
>> The only way how to deal with that is to make particular symbol
>> (sub)instance to be either
>> an instance of Symbol or Selector but not both.
>> This means that in system you could have either
>> #foo
>> or
>> #foo asSelector
>> but not both, otherwise you will violate the uniqueness rule.
>
> the problem you see is, as I said above, because you are subclassing symbol
> which is not what I would do.
>

So, you want a completely separate class for selectors,
which by sending #name (for instance) will answer a symbol which
identifies them?

yes
 
I see, use delegation instead of inheritance.

yes 

But then, technically, this means that for each symbol, which used as
selector, you will need to add
an additional instance of Selector, which wraps around symbol.

no, it does not wraps around... it has a completely different set of messages that it responds to, it does not wrap it, because if in that situation we say that selector wraps a symbol, then a date wraps a number (its day number), and Character wraps a number (its value), etc. Symbols and selectors are not completely polymorphic under the model I propose, the same way Character is not completely polymorphic with Number, etc. 
If I understand your point, you should not have Character because it only holds a Number ? is that right?
 
Sounds not very good.
But maybe there are benefits, which outweights such memory increase?
Tell me more.

well I think I made my point very clear, you care about memory usage I care about object responsibilities, you care about implementation I care about design that encapsulates implementation... so I don't think we will agree until either one changes his vision on what it is more important... and I will not hehe (just kidding)


It reminds me a MethodReference.
It also identifies a CompiledMethod, without referring directly to
class or method.
But if you look closer at its implementation, you'll see that it is
used as a dumb state holder,
grouping different aspects of a method's state.
It is used extensively by browser tools, even in places, where you
could use and talk with compiled methods directly.
Needless to say, that i can't understand such approach: why one would
need to wrap things with a proxy,
only to access the state of an object of interest though it? Why an
object of interest can't give same answers directly?

I would understand that tools could be made so, that they can work
with real objects as well as with proxies,
which both honoring same protocol.
But blindly wrapping each object with proxy?? This is beyond my
understanding abilities.


I can't comment based on your description, I don't know MethodReference, what represents and what it is used for... sorry, cant help here.
 
>>
>> Objects could play many roles, depending on their use. Just take a
>> look at Object protocol, and answer yourself, how
>> many of these methods is userful in some specific case (such as an
>> object used to identify a message - selector).
>> So, if you want to dissect all roles onto a set of specific
>> (sub)classes, i propose to start from an Object class,
>> and then, gradually get to a Symbol.
>
> Not a bad idea!! Object is completely out of control and we should remove a
> lot of the methods it has! I completely agree there :-)
>
Hehe. Good luck with that :)

thanks! but I'm not going to do it... I would start from zero than trying to fix something that is already broken :-)
 
Sure thing, i'd like to see less methods in Object class.

But "Object class" has no methods! it is Object that has a lot of methods! (just kidding, I know you mean the class Object and no "Object class")

Bye!
Hernan.


>>
>> > This idea brings implementation challenges of course, but nothing new
>> > :-)
>> > On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
>> > <[hidden email]> wrote:
>> >>
>> >> :)
>> >>
>> >> Your previous mail was what the bee I had in my bonnet :)
>> >>
>> >> Stef
>> >>
>> >> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>> >>
>> >> > Actually I think is one of the better ideas I've read in this list.
>> >> > Too bad nobody seems interested in semiotics :(
>> >> >
>> >> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> >> >> I;m sorry that I raised a stupid idea.
>> >> >> Don;t bash people for me :)
>> >> >>
>> >> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>> >> >>
>> >> >>> Hi guys
>> >> >>>
>> >> >>> I'm thinking aloud...
>> >> >>> I was wondering if we could not take advantage of a new class:
>> >> >>> Selector.
>> >> >>> MethodDict would only contain selectors and not symbols.
>> >> >>>
>> >> >>> I remember that I talked about that with hernan.
>> >> >>>
>> >> >>> Stef
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Pharo-users mailing list
>> >> >>> [hidden email]
>> >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Pharo-users mailing list
>> >> >> [hidden email]
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-users mailing list
>> >> > [hidden email]
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >>
>> >>
>> >> _______________________________________________
>> >> Pharo-users mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>> >
>> > --
>> > Hernán Wilkinson
>> > Agile Software Development, Teaching & Coaching
>> > Mobile: +54 - 11 - 4470 - 7207
>> > email: [hidden email]
>> > site: http://www.10Pines.com
>> >
>> > _______________________________________________
>> > Pharo-users mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>



--
Best regards,
Igor Stasenko AKA sig.

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



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Igor Stasenko
On 26 August 2010 04:09, Hernan Wilkinson <[hidden email]> wrote:

>
>
> On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 25 August 2010 23:08, Hernan Wilkinson <[hidden email]>
>> wrote:
>> >
>> >
>> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <[hidden email]>
>> > wrote:
>> >>
>> >> On 25 August 2010 21:11, Hernan Wilkinson
>> >> <[hidden email]>
>> >> wrote:
>> >> > From the design point of view, I like the idea, a selector is not a
>> >> > symbol
>> >> > and we can see that clearly in the Symbol protocol, like Mariano and
>> >> > Gabriel
>> >> > said, implements messages that are related to selector behavior...
>> >> > Why
>> >> > symbols respond to numArgs:, precedence, isUnary, etc? those are a
>> >> > selectors
>> >> > responsibilities... not all symbols are selectors... so for me, it is
>> >> > a
>> >> > good
>> >> > idea.
>> >>
>> >> not all symbols are selectors...
>> >> but you never tell, that they could not be, once you load new package
>> >> or write more code.
>> >>
>> >> I see the need of having a separate subclass for Symbol , instead of
>> >> stopping at String,
>> >> because it have to maintain uniqueness and immutability.
>> >>
>> >> String + uniqueness + immutability => Symbol
>> >>
>> >> so, there is a strong reason for having a separate class for it, but
>> >>
>> >> Symbol + ??? => Selector
>> >>
>> >> give me a strong reason.
>> >
>> > meaning, semantic... that I thing are stronger reasons that uniqueness
>> > for
>> > example, because uniqueness is an implementation issue, meaning is not.
>> > Immutability is not an implementation issue is part of the semantic of
>> > the
>> > object.
>> >
>>
>> Meaning could be anything. It depends from context where i using this
>> object.
>
> hmmm, for me the meaning of an object is given by the messages it knows how
> to respond, no context related. I'm talking about objects defined in a
> formal language, not of entities described in natural language where context
> influences meaning...
>

I don't know what you mean by 'meaning of an object in a formal language'.
For me, an object's meaning (or in other words, its role) always
derives from context, where it is used,
not from its class or implementation.
Classes are not 'specification of roles'. They are orthogonal to them
and just providing an object's
behavior. Classes do not restricting me from using objects
for different roles, even not intended ones originally.
That's why i see nothing wrong when symbols in one context plays role
as selector,
in other as dictionary keys, or class names , a collection element etc etc.
It is pointless to try and predict all possible roles, which object
may play in different contexts,
and try to implement all of them in separate class(es).

>>
>> From machine's point of view there is no meaning, only semantic.
>
> hehe, I thought that machines only treated symbols, therefore they are
> incapable to provide semantic to them... only we human can provide meaning
> (that for me is the same as semantic in this context :-) ), so we have basic
> differences in fundamental concepts... I don't think we will agree therefore
> on high level ones...
>>
>> So, i am asking, what _technical_ benefits it would brings us.
>
> I don't care about technical benefits, I care about modeling benefits. I
> leave the technical issues to the computer that does not get tired when
> doing things over and over again... :-).

you know, why i don't like rebooting my PC? i am tired waiting, for
system booting, since over last 20 years, computers became 10 times
faster (or even more),
while at the same time, their boot time increasing and increasing over and over.
So, please, don't say to me, that technical side is not worth to consider.

> Asking only for technical benefits of a solution is like asking why do we
> have garbage collection? what is the technical benefit of it? it takes more
> time that manually deleting objects, it needs more memory, etc. so what is
> its technical benefit? none... the benefit is for us, because it allow us to
> delegate the memory management responsibility to the computer (a repetitive
> process) and free our mind to concentrate on important issues
>

Well, i went to technical benefits only because i don't see any strong
modeling ones, which worth time spent on:
- refactoring class/metaclass model
- changing compiler
- changing all tools to use selectors instead of symbols
- etc etc etc

really, think about how much must be done to introduce it over existing system,
and only to dissect a minor subset of behavior from Symbol class..
Come on.
Do we really have nothing else to do, more important to change/improve?

I agree, such change may help developers in better understanding the system.
But for most developers, who busy doing own projects, not related with depths of
a system organization and compiler/browser framework, i really don't
see big quality shift
comparing to current scheme.
The fact that currently, Symbols playing role as selectors doesn't
prevents me from
writing good code, and i doubt that even if you change that, it will
help me in anything
except mentioned above.

Good model is a balance between simplicity, clarity and technical sides.
While adding Selector improves clarity, at same time it increasing complexity,
and worsening a technical side, since it will lead to increased memory
footprint.


>>
>> Because from meaning point of view, a symbol #foo reads foo,
>> as well as selector foo, and only we (humans) know that it is selector
>> in one context,
>> or just a simple 'unique string' in another one.
>>
>> >>
>> >> i like the idea of shrinking a Symbol's protocol and putting it into
>> >> lean and clean place - Symbol.
>> >> But this is not strong enough.
>> >> In practice, such shrinking, could lead to explosion of complexity in
>> >> many other places.
>> >>
>> >>
>> >> 'foo' = #foo  ->true
>> >> #foo = 'foo' -> true
>> >>
>> >> #foo asSelector = #foo ??
>> >
>> > clearly no, we are saying that a symbol should be different from a
>> > selector,
>> > therefore they should never be equal no matter if their
>> > "printable" representation is the same (as in this example #foo)
>> >>
>> >> if so, then
>> >> #foo hash = #foo asSelector hash ?
>> >
>> > could or could not... depends on the implementation, who cares?
>> >
>> >>
>> >> and , obviously
>> >> #foo == #foo asSelector  => false
>> >
>> > yes, and #foo = #foo asSelector --> false
>> >
>> >>
>> >> which means, that mixing selectors and symbols in a single collection
>> >> will be very bad idea,
>> >> and source of bugs and confusion.
>> >
>> > why?
>> > It is not the same the relationship between a symbol and a string that
>> > with
>> > a symbol and a selector.
>> > We could say that a symbol and a string represent a sequence of
>> > characters,
>> > so if they represent the same sequence of characters they have to be
>> > equal,
>> > that is why #foo = 'foo', (that means 'foo' asUniqueString = 'foo' where
>> > asUniqueString is the real meaning of the # in front of the symbols...),
>> > but
>> > a selector does not represent a sequence of character, it represents the
>> > name of a message. Therefore for me a selector has a "name" that is a
>> > symbol, but a selector IS NOT a symbol, because can answer messages like
>> > numOfArgs:, sendTo: etc.
>>
>> it could have a sense to use different entity, when you would need to
>> hold additional state.
>> I can imagine a class, like 'measure unit', with two variables - value
>> and units.
>> So, you can express 1 cm, 1 mm, 1 km, 100 kg using such object.
>> But in case of selectors , you expressing a symbol, and there is no
>> need for additional state.
>
> Different objects are not only created because they have different "state"
> but because they have different responsibilities, for me that is the central
> issue, and as I said before I see that we do not agree on fundamental issues
> so...
>
i don't feel that selectors are so different from symbols, that its
worth making a
separate class.

>>
>> >>
>> >> But what gives us a uniqueness of symbols is, that we don't need to
>> >> use #= for comparing them,
>> >> but #== , which is much faster. Right?
>> >
>> > well, I think that using #== is a wrong design decision, for me you
>> > should
>> > only use #== if you are dealing with "memory" issues, if you really want
>> > two
>> > objects to be in the same memory position, therefore it is an
>> > implementation
>> > issue, but no if you are designing for extensibility....
>> >
>> >>
>> >> Now, if you introduce selectors, there is no uniqueness anymore,
>> >
>> > why?
>> >
>>
>> well, because two things which having same name should be equal.
>> Otherwise it makes no sense to use same name for them.
>> Keep in mind, that symbols are made for humans. Machine feels pretty well
>> with
>> pointers and don't needs to know anything about names.
>
> but programs are made by humans, read by humans and maintain by humans, so
> that is why we have symbol instead of pointers and true instead of 1 and
> false instead of 0... for us, not for the machine.
> I don't understand why you say that there will be no more uniqueness, a
> selector can be unique per its name or not, that is an implementation issue,
> that is, how much memory you want to consume... the important thing is that
> selectors with the same name should be equal, who cares if they share the
> same memory position? only the implementor of the vm... I don't care if
> "Date today == Date today", I do care that "Date today = Date today"... if
> tomorrow the Date implementor decides to do "Date today == Date today",
> good, that is an implementation issue, could be good could be bad, and I as
> a user of Date should not care.
>>
>> >>
>> >> since
>> >> selector is a symbol (since it is a subclass of it),
>> >
>> > why? I would not make it a subclass... using a subclass only to reuse
>> > code
>> > it is a bad design decision from my point of view, Selector should be a
>> > class by itself whose instances know a name, that are instances of
>> > Symbol
>> >>
>> >> and must honor
>> >> the rules of its ancestor..
>> >> but its not.
>> >> The only way how to deal with that is to make particular symbol
>> >> (sub)instance to be either
>> >> an instance of Symbol or Selector but not both.
>> >> This means that in system you could have either
>> >> #foo
>> >> or
>> >> #foo asSelector
>> >> but not both, otherwise you will violate the uniqueness rule.
>> >
>> > the problem you see is, as I said above, because you are subclassing
>> > symbol
>> > which is not what I would do.
>> >
>>
>> So, you want a completely separate class for selectors,
>> which by sending #name (for instance) will answer a symbol which
>> identifies them?
>
> yes
>
>>
>> I see, use delegation instead of inheritance.
>
> yes
>>
>> But then, technically, this means that for each symbol, which used as
>> selector, you will need to add
>> an additional instance of Selector, which wraps around symbol.
>
> no, it does not wraps around... it has a completely different set of
> messages that it responds to, it does not wrap it, because if in that
> situation we say that selector wraps a symbol, then a date wraps a number
> (its day number), and Character wraps a number (its value), etc. Symbols and
> selectors are not completely polymorphic under the model I propose, the same
> way Character is not completely polymorphic with Number, etc.
> If I understand your point, you should not have Character because it only
> holds a Number ? is that right?
>

Character and Number is quite different by nature.
As to me, for Symbol/Selector a better analogy would be Fruit and Apple.

>>
>> Sounds not very good.
>> But maybe there are benefits, which outweights such memory increase?
>> Tell me more.
>
> well I think I made my point very clear, you care about memory usage I care
> about object responsibilities, you care about implementation I care about
> design that encapsulates implementation... so I don't think we will agree
> until either one changes his vision on what it is more important... and I
> will not hehe (just kidding)

I care about all sides of it. And i'm not ready to sacrifice a memory usage
for that. There's a lot more better places where i could put a free
memory in use :)

>>
>> It reminds me a MethodReference.
>> It also identifies a CompiledMethod, without referring directly to
>> class or method.
>> But if you look closer at its implementation, you'll see that it is
>> used as a dumb state holder,
>> grouping different aspects of a method's state.
>> It is used extensively by browser tools, even in places, where you
>> could use and talk with compiled methods directly.
>> Needless to say, that i can't understand such approach: why one would
>> need to wrap things with a proxy,
>> only to access the state of an object of interest though it? Why an
>> object of interest can't give same answers directly?
>>
>> I would understand that tools could be made so, that they can work
>> with real objects as well as with proxies,
>> which both honoring same protocol.
>> But blindly wrapping each object with proxy?? This is beyond my
>> understanding abilities.
>>
>
> I can't comment based on your description, I don't know MethodReference,
> what represents and what it is used for... sorry, cant help here.
>
>>
>> >>
>> >> Objects could play many roles, depending on their use. Just take a
>> >> look at Object protocol, and answer yourself, how
>> >> many of these methods is userful in some specific case (such as an
>> >> object used to identify a message - selector).
>> >> So, if you want to dissect all roles onto a set of specific
>> >> (sub)classes, i propose to start from an Object class,
>> >> and then, gradually get to a Symbol.
>> >
>> > Not a bad idea!! Object is completely out of control and we should
>> > remove a
>> > lot of the methods it has! I completely agree there :-)
>> >
>> Hehe. Good luck with that :)
>
> thanks! but I'm not going to do it... I would start from zero than trying to
> fix something that is already broken :-)
>
>>
>> Sure thing, i'd like to see less methods in Object class.
>
> But "Object class" has no methods! it is Object that has a lot of methods!
> (just kidding, I know you mean the class Object and no "Object class")
> Bye!
> Hernan.
>>
>> >>
>> >> > This idea brings implementation challenges of course, but nothing new
>> >> > :-)
>> >> > On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >> :)
>> >> >>
>> >> >> Your previous mail was what the bee I had in my bonnet :)
>> >> >>
>> >> >> Stef
>> >> >>
>> >> >> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>> >> >>
>> >> >> > Actually I think is one of the better ideas I've read in this
>> >> >> > list.
>> >> >> > Too bad nobody seems interested in semiotics :(
>> >> >> >
>> >> >> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> >> >> >> I;m sorry that I raised a stupid idea.
>> >> >> >> Don;t bash people for me :)
>> >> >> >>
>> >> >> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>> >> >> >>
>> >> >> >>> Hi guys
>> >> >> >>>
>> >> >> >>> I'm thinking aloud...
>> >> >> >>> I was wondering if we could not take advantage of a new class:
>> >> >> >>> Selector.
>> >> >> >>> MethodDict would only contain selectors and not symbols.
>> >> >> >>>
>> >> >> >>> I remember that I talked about that with hernan.
>> >> >> >>>
>> >> >> >>> Stef
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> Pharo-users mailing list
>> >> >> >>> [hidden email]
>> >> >> >>>
>> >> >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >> >>
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Pharo-users mailing list
>> >> >> >> [hidden email]
>> >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >> >>
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Pharo-users mailing list
>> >> >> > [hidden email]
>> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Pharo-users mailing list
>> >> >> [hidden email]
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Hernán Wilkinson
>> >> > Agile Software Development, Teaching & Coaching
>> >> > Mobile: +54 - 11 - 4470 - 7207
>> >> > email: [hidden email]
>> >> > site: http://www.10Pines.com
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-users mailing list
>> >> > [hidden email]
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >>
>> >> _______________________________________________
>> >> Pharo-users mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>> >
>> > --
>> > Hernán Wilkinson
>> > Agile Software Development, Teaching & Coaching
>> > Mobile: +54 - 11 - 4470 - 7207
>> > email: [hidden email]
>> > site: http://www.10Pines.com
>> >
>> > _______________________________________________
>> > Pharo-users mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

hernanmd
In reply to this post by Igor Stasenko
2010/8/25 Igor Stasenko <[hidden email]>:
>>
>
> Meaning could be anything. It depends from context where i using this object.
> From machine's point of view there is no meaning, only semantic.
>

Igor, there are *TONS* of books about meaning (Saussure, Eco,
Wittgenstein, etc), meaning is everything but anything. The richer
understanding of meaning the better you are understanding systems.

And there is no semantic from a machine's point of view (it was a
claim of strong AI for many years).

> So, i am asking, what _technical_ benefits it would brings us.

From a functionalist point of view, there are no additional benefits.

> Because from meaning point of view, a symbol #foo reads foo,
> as well as selector foo, and only we (humans) know that it is selector
> in one context,
> or just a simple 'unique string' in another one.
>
>>>
>>> i like the idea of shrinking a Symbol's protocol and putting it into
>>> lean and clean place - Symbol.
>>> But this is not strong enough.
>>> In practice, such shrinking, could lead to explosion of complexity in
>>> many other places.
>>>
>>>
>>> 'foo' = #foo  ->true
>>> #foo = 'foo' -> true
>>>
>>> #foo asSelector = #foo ??
>>
>> clearly no, we are saying that a symbol should be different from a selector,
>> therefore they should never be equal no matter if their
>> "printable" representation is the same (as in this example #foo)
>>>
>>> if so, then
>>> #foo hash = #foo asSelector hash ?
>>
>> could or could not... depends on the implementation, who cares?
>>
>>>
>>> and , obviously
>>> #foo == #foo asSelector  => false
>>
>> yes, and #foo = #foo asSelector --> false
>>
>>>
>>> which means, that mixing selectors and symbols in a single collection
>>> will be very bad idea,
>>> and source of bugs and confusion.
>>
>> why?
>> It is not the same the relationship between a symbol and a string that with
>> a symbol and a selector.
>> We could say that a symbol and a string represent a sequence of characters,
>> so if they represent the same sequence of characters they have to be equal,
>> that is why #foo = 'foo', (that means 'foo' asUniqueString = 'foo' where
>> asUniqueString is the real meaning of the # in front of the symbols...), but
>> a selector does not represent a sequence of character, it represents the
>> name of a message. Therefore for me a selector has a "name" that is a
>> symbol, but a selector IS NOT a symbol, because can answer messages like
>> numOfArgs:, sendTo: etc.
>
> it could have a sense to use different entity, when you would need to
> hold additional state.
> I can imagine a class, like 'measure unit', with two variables - value
> and units.
> So, you can express 1 cm, 1 mm, 1 km, 100 kg using such object.
> But in case of selectors , you expressing a symbol, and there is no
> need for additional state.
>

A selector could have an intention, a duration or time of life (have
you ever heard about mRNA?), an impact factor, a context (to validate
its application), etc. A lot of very interesting and new things could
be done!
Ok, may be there is no need for this at all, but there is no need for
hundreds of natural or artifficial languages too.

>>>
>>> But what gives us a uniqueness of symbols is, that we don't need to
>>> use #= for comparing them,
>>> but #== , which is much faster. Right?
>>
>> well, I think that using #== is a wrong design decision, for me you should
>> only use #== if you are dealing with "memory" issues, if you really want two
>> objects to be in the same memory position, therefore it is an implementation
>> issue, but no if you are designing for extensibility....
>>
>>>
>>> Now, if you introduce selectors, there is no uniqueness anymore,
>>
>> why?
>>
>
> well, because two things which having same name should be equal.
> Otherwise it makes no sense to use same name for them.

And what we do with polysemic names? :)

> Keep in mind, that symbols are made for humans. Machine feels pretty well with
> pointers and don't needs to know anything about names.
>
>>>
>>> since
>>> selector is a symbol (since it is a subclass of it),
>>
>> why? I would not make it a subclass... using a subclass only to reuse code
>> it is a bad design decision from my point of view, Selector should be a
>> class by itself whose instances know a name, that are instances of Symbol
>>>
>>> and must honor
>>> the rules of its ancestor..
>>> but its not.
>>> The only way how to deal with that is to make particular symbol
>>> (sub)instance to be either
>>> an instance of Symbol or Selector but not both.
>>> This means that in system you could have either
>>> #foo
>>> or
>>> #foo asSelector
>>> but not both, otherwise you will violate the uniqueness rule.
>>
>> the problem you see is, as I said above, because you are subclassing symbol
>> which is not what I would do.
>>
>
> So, you want a completely separate class for selectors,
> which by sending #name (for instance) will answer a symbol which
> identifies them?
> I see, use delegation instead of inheritance.
>

Sorry I cannot comment about implementation because I'm not too
interested in super technical issues, but I recognize the difficulty
:)

Cheers,

Hernán

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: funny idea Symbol vs. Selector

Hernan Wilkinson-3
In reply to this post by Igor Stasenko
as I said in my first mail, I think it is a good idea from the design point of view, should it be implemented now? I dont think so, as you say, there are other more important things to do in pharo, but the idea is good.

Bye!
Hernan.

On Thu, Aug 26, 2010 at 12:27 AM, Igor Stasenko <[hidden email]> wrote:
On 26 August 2010 04:09, Hernan Wilkinson <[hidden email]> wrote:
>
>
> On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 25 August 2010 23:08, Hernan Wilkinson <[hidden email]>
>> wrote:
>> >
>> >
>> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <[hidden email]>
>> > wrote:
>> >>
>> >> On 25 August 2010 21:11, Hernan Wilkinson
>> >> <[hidden email]>
>> >> wrote:
>> >> > From the design point of view, I like the idea, a selector is not a
>> >> > symbol
>> >> > and we can see that clearly in the Symbol protocol, like Mariano and
>> >> > Gabriel
>> >> > said, implements messages that are related to selector behavior...
>> >> > Why
>> >> > symbols respond to numArgs:, precedence, isUnary, etc? those are a
>> >> > selectors
>> >> > responsibilities... not all symbols are selectors... so for me, it is
>> >> > a
>> >> > good
>> >> > idea.
>> >>
>> >> not all symbols are selectors...
>> >> but you never tell, that they could not be, once you load new package
>> >> or write more code.
>> >>
>> >> I see the need of having a separate subclass for Symbol , instead of
>> >> stopping at String,
>> >> because it have to maintain uniqueness and immutability.
>> >>
>> >> String + uniqueness + immutability => Symbol
>> >>
>> >> so, there is a strong reason for having a separate class for it, but
>> >>
>> >> Symbol + ??? => Selector
>> >>
>> >> give me a strong reason.
>> >
>> > meaning, semantic... that I thing are stronger reasons that uniqueness
>> > for
>> > example, because uniqueness is an implementation issue, meaning is not.
>> > Immutability is not an implementation issue is part of the semantic of
>> > the
>> > object.
>> >
>>
>> Meaning could be anything. It depends from context where i using this
>> object.
>
> hmmm, for me the meaning of an object is given by the messages it knows how
> to respond, no context related. I'm talking about objects defined in a
> formal language, not of entities described in natural language where context
> influences meaning...
>

I don't know what you mean by 'meaning of an object in a formal language'.
For me, an object's meaning (or in other words, its role) always
derives from context, where it is used,
not from its class or implementation.
Classes are not 'specification of roles'. They are orthogonal to them
and just providing an object's
behavior. Classes do not restricting me from using objects
for different roles, even not intended ones originally.
That's why i see nothing wrong when symbols in one context plays role
as selector,
in other as dictionary keys, or class names , a collection element etc etc.
It is pointless to try and predict all possible roles, which object
may play in different contexts,
and try to implement all of them in separate class(es).

>>
>> From machine's point of view there is no meaning, only semantic.
>
> hehe, I thought that machines only treated symbols, therefore they are
> incapable to provide semantic to them... only we human can provide meaning
> (that for me is the same as semantic in this context :-) ), so we have basic
> differences in fundamental concepts... I don't think we will agree therefore
> on high level ones...
>>
>> So, i am asking, what _technical_ benefits it would brings us.
>
> I don't care about technical benefits, I care about modeling benefits. I
> leave the technical issues to the computer that does not get tired when
> doing things over and over again... :-).

you know, why i don't like rebooting my PC? i am tired waiting, for
system booting, since over last 20 years, computers became 10 times
faster (or even more),
while at the same time, their boot time increasing and increasing over and over.
So, please, don't say to me, that technical side is not worth to consider.

> Asking only for technical benefits of a solution is like asking why do we
> have garbage collection? what is the technical benefit of it? it takes more
> time that manually deleting objects, it needs more memory, etc. so what is
> its technical benefit? none... the benefit is for us, because it allow us to
> delegate the memory management responsibility to the computer (a repetitive
> process) and free our mind to concentrate on important issues
>

Well, i went to technical benefits only because i don't see any strong
modeling ones, which worth time spent on:
- refactoring class/metaclass model
- changing compiler
- changing all tools to use selectors instead of symbols
- etc etc etc

really, think about how much must be done to introduce it over existing system,
and only to dissect a minor subset of behavior from Symbol class..
Come on.
Do we really have nothing else to do, more important to change/improve?

I agree, such change may help developers in better understanding the system.
But for most developers, who busy doing own projects, not related with depths of
a system organization and compiler/browser framework, i really don't
see big quality shift
comparing to current scheme.
The fact that currently, Symbols playing role as selectors doesn't
prevents me from
writing good code, and i doubt that even if you change that, it will
help me in anything
except mentioned above.

Good model is a balance between simplicity, clarity and technical sides.
While adding Selector improves clarity, at same time it increasing complexity,
and worsening a technical side, since it will lead to increased memory
footprint.


>>
>> Because from meaning point of view, a symbol #foo reads foo,
>> as well as selector foo, and only we (humans) know that it is selector
>> in one context,
>> or just a simple 'unique string' in another one.
>>
>> >>
>> >> i like the idea of shrinking a Symbol's protocol and putting it into
>> >> lean and clean place - Symbol.
>> >> But this is not strong enough.
>> >> In practice, such shrinking, could lead to explosion of complexity in
>> >> many other places.
>> >>
>> >>
>> >> 'foo' = #foo  ->true
>> >> #foo = 'foo' -> true
>> >>
>> >> #foo asSelector = #foo ??
>> >
>> > clearly no, we are saying that a symbol should be different from a
>> > selector,
>> > therefore they should never be equal no matter if their
>> > "printable" representation is the same (as in this example #foo)
>> >>
>> >> if so, then
>> >> #foo hash = #foo asSelector hash ?
>> >
>> > could or could not... depends on the implementation, who cares?
>> >
>> >>
>> >> and , obviously
>> >> #foo == #foo asSelector  => false
>> >
>> > yes, and #foo = #foo asSelector --> false
>> >
>> >>
>> >> which means, that mixing selectors and symbols in a single collection
>> >> will be very bad idea,
>> >> and source of bugs and confusion.
>> >
>> > why?
>> > It is not the same the relationship between a symbol and a string that
>> > with
>> > a symbol and a selector.
>> > We could say that a symbol and a string represent a sequence of
>> > characters,
>> > so if they represent the same sequence of characters they have to be
>> > equal,
>> > that is why #foo = 'foo', (that means 'foo' asUniqueString = 'foo' where
>> > asUniqueString is the real meaning of the # in front of the symbols...),
>> > but
>> > a selector does not represent a sequence of character, it represents the
>> > name of a message. Therefore for me a selector has a "name" that is a
>> > symbol, but a selector IS NOT a symbol, because can answer messages like
>> > numOfArgs:, sendTo: etc.
>>
>> it could have a sense to use different entity, when you would need to
>> hold additional state.
>> I can imagine a class, like 'measure unit', with two variables - value
>> and units.
>> So, you can express 1 cm, 1 mm, 1 km, 100 kg using such object.
>> But in case of selectors , you expressing a symbol, and there is no
>> need for additional state.
>
> Different objects are not only created because they have different "state"
> but because they have different responsibilities, for me that is the central
> issue, and as I said before I see that we do not agree on fundamental issues
> so...
>
i don't feel that selectors are so different from symbols, that its
worth making a
separate class.

>>
>> >>
>> >> But what gives us a uniqueness of symbols is, that we don't need to
>> >> use #= for comparing them,
>> >> but #== , which is much faster. Right?
>> >
>> > well, I think that using #== is a wrong design decision, for me you
>> > should
>> > only use #== if you are dealing with "memory" issues, if you really want
>> > two
>> > objects to be in the same memory position, therefore it is an
>> > implementation
>> > issue, but no if you are designing for extensibility....
>> >
>> >>
>> >> Now, if you introduce selectors, there is no uniqueness anymore,
>> >
>> > why?
>> >
>>
>> well, because two things which having same name should be equal.
>> Otherwise it makes no sense to use same name for them.
>> Keep in mind, that symbols are made for humans. Machine feels pretty well
>> with
>> pointers and don't needs to know anything about names.
>
> but programs are made by humans, read by humans and maintain by humans, so
> that is why we have symbol instead of pointers and true instead of 1 and
> false instead of 0... for us, not for the machine.
> I don't understand why you say that there will be no more uniqueness, a
> selector can be unique per its name or not, that is an implementation issue,
> that is, how much memory you want to consume... the important thing is that
> selectors with the same name should be equal, who cares if they share the
> same memory position? only the implementor of the vm... I don't care if
> "Date today == Date today", I do care that "Date today = Date today"... if
> tomorrow the Date implementor decides to do "Date today == Date today",
> good, that is an implementation issue, could be good could be bad, and I as
> a user of Date should not care.
>>
>> >>
>> >> since
>> >> selector is a symbol (since it is a subclass of it),
>> >
>> > why? I would not make it a subclass... using a subclass only to reuse
>> > code
>> > it is a bad design decision from my point of view, Selector should be a
>> > class by itself whose instances know a name, that are instances of
>> > Symbol
>> >>
>> >> and must honor
>> >> the rules of its ancestor..
>> >> but its not.
>> >> The only way how to deal with that is to make particular symbol
>> >> (sub)instance to be either
>> >> an instance of Symbol or Selector but not both.
>> >> This means that in system you could have either
>> >> #foo
>> >> or
>> >> #foo asSelector
>> >> but not both, otherwise you will violate the uniqueness rule.
>> >
>> > the problem you see is, as I said above, because you are subclassing
>> > symbol
>> > which is not what I would do.
>> >
>>
>> So, you want a completely separate class for selectors,
>> which by sending #name (for instance) will answer a symbol which
>> identifies them?
>
> yes
>
>>
>> I see, use delegation instead of inheritance.
>
> yes
>>
>> But then, technically, this means that for each symbol, which used as
>> selector, you will need to add
>> an additional instance of Selector, which wraps around symbol.
>
> no, it does not wraps around... it has a completely different set of
> messages that it responds to, it does not wrap it, because if in that
> situation we say that selector wraps a symbol, then a date wraps a number
> (its day number), and Character wraps a number (its value), etc. Symbols and
> selectors are not completely polymorphic under the model I propose, the same
> way Character is not completely polymorphic with Number, etc.
> If I understand your point, you should not have Character because it only
> holds a Number ? is that right?
>

Character and Number is quite different by nature.
As to me, for Symbol/Selector a better analogy would be Fruit and Apple.

>>
>> Sounds not very good.
>> But maybe there are benefits, which outweights such memory increase?
>> Tell me more.
>
> well I think I made my point very clear, you care about memory usage I care
> about object responsibilities, you care about implementation I care about
> design that encapsulates implementation... so I don't think we will agree
> until either one changes his vision on what it is more important... and I
> will not hehe (just kidding)

I care about all sides of it. And i'm not ready to sacrifice a memory usage
for that. There's a lot more better places where i could put a free
memory in use :)

>>
>> It reminds me a MethodReference.
>> It also identifies a CompiledMethod, without referring directly to
>> class or method.
>> But if you look closer at its implementation, you'll see that it is
>> used as a dumb state holder,
>> grouping different aspects of a method's state.
>> It is used extensively by browser tools, even in places, where you
>> could use and talk with compiled methods directly.
>> Needless to say, that i can't understand such approach: why one would
>> need to wrap things with a proxy,
>> only to access the state of an object of interest though it? Why an
>> object of interest can't give same answers directly?
>>
>> I would understand that tools could be made so, that they can work
>> with real objects as well as with proxies,
>> which both honoring same protocol.
>> But blindly wrapping each object with proxy?? This is beyond my
>> understanding abilities.
>>
>
> I can't comment based on your description, I don't know MethodReference,
> what represents and what it is used for... sorry, cant help here.
>
>>
>> >>
>> >> Objects could play many roles, depending on their use. Just take a
>> >> look at Object protocol, and answer yourself, how
>> >> many of these methods is userful in some specific case (such as an
>> >> object used to identify a message - selector).
>> >> So, if you want to dissect all roles onto a set of specific
>> >> (sub)classes, i propose to start from an Object class,
>> >> and then, gradually get to a Symbol.
>> >
>> > Not a bad idea!! Object is completely out of control and we should
>> > remove a
>> > lot of the methods it has! I completely agree there :-)
>> >
>> Hehe. Good luck with that :)
>
> thanks! but I'm not going to do it... I would start from zero than trying to
> fix something that is already broken :-)
>
>>
>> Sure thing, i'd like to see less methods in Object class.
>
> But "Object class" has no methods! it is Object that has a lot of methods!
> (just kidding, I know you mean the class Object and no "Object class")
> Bye!
> Hernan.
>>
>> >>
>> >> > This idea brings implementation challenges of course, but nothing new
>> >> > :-)
>> >> > On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >> :)
>> >> >>
>> >> >> Your previous mail was what the bee I had in my bonnet :)
>> >> >>
>> >> >> Stef
>> >> >>
>> >> >> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>> >> >>
>> >> >> > Actually I think is one of the better ideas I've read in this
>> >> >> > list.
>> >> >> > Too bad nobody seems interested in semiotics :(
>> >> >> >
>> >> >> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>> >> >> >> I;m sorry that I raised a stupid idea.
>> >> >> >> Don;t bash people for me :)
>> >> >> >>
>> >> >> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>> >> >> >>
>> >> >> >>> Hi guys
>> >> >> >>>
>> >> >> >>> I'm thinking aloud...
>> >> >> >>> I was wondering if we could not take advantage of a new class:
>> >> >> >>> Selector.
>> >> >> >>> MethodDict would only contain selectors and not symbols.
>> >> >> >>>
>> >> >> >>> I remember that I talked about that with hernan.
>> >> >> >>>
>> >> >> >>> Stef
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> Pharo-users mailing list
>> >> >> >>> [hidden email]
>> >> >> >>>
>> >> >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >> >>
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Pharo-users mailing list
>> >> >> >> [hidden email]
>> >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >> >>
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Pharo-users mailing list
>> >> >> > [hidden email]
>> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Pharo-users mailing list
>> >> >> [hidden email]
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Hernán Wilkinson
>> >> > Agile Software Development, Teaching & Coaching
>> >> > Mobile: +54 - 11 - 4470 - 7207
>> >> > email: [hidden email]
>> >> > site: http://www.10Pines.com
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-users mailing list
>> >> > [hidden email]
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >>
>> >> _______________________________________________
>> >> Pharo-users mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>> >
>> > --
>> > Hernán Wilkinson
>> > Agile Software Development, Teaching & Coaching
>> > Mobile: +54 - 11 - 4470 - 7207
>> > email: [hidden email]
>> > site: http://www.10Pines.com
>> >
>> > _______________________________________________
>> > Pharo-users mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>



--
Best regards,
Igor Stasenko AKA sig.

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



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


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