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