On 26 August 2010 08:20, Hernán Morales Durand <[email protected]> wrote: > 2010/8/25 Igor Stasenko <[email protected]>: >>> >> >> 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). >
Well, from machine POV, there is nothing but just electric signals, which form bytes, and those bytes form various structures in memory. I agree, that anything extra, what we putting into it (meaning, semantic) is a human-centric. >> 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? :) > Let me guess: we are deduce its meaning depending on context, where its used. That's exactly the case with symbol/selector :) >> 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 > :) > Anyways, thanks for discussion. :) > Cheers, > > Hernán > > _______________________________________________ > Pharo-users mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
