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). > 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
