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 <[email protected]> wrote: > On 26 August 2010 04:09, Hernan Wilkinson <[email protected]> > wrote: > > > > > > On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <[email protected]> > wrote: > >> > >> On 25 August 2010 23:08, Hernan Wilkinson <[email protected] > > > >> wrote: > >> > > >> > > >> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <[email protected]> > >> > wrote: > >> >> > >> >> On 25 August 2010 21:11, Hernan Wilkinson > >> >> <[email protected]> > >> >> 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 > >> >> > <[email protected]> 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 <[email protected]>: > >> >> >> >> 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 > >> >> >> >>> [email protected] > >> >> >> >>> > >> >> >> >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> >> >> > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Pharo-users mailing list > >> >> >> >> [email protected] > >> >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> >> >> > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > Pharo-users mailing list > >> >> >> > [email protected] > >> >> >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Pharo-users mailing list > >> >> >> [email protected] > >> >> >> 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: [email protected] > >> >> > site: http://www.10Pines.com > >> >> > > >> >> > _______________________________________________ > >> >> > 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 > >> > > >> > > >> > > >> > -- > >> > Hernán Wilkinson > >> > Agile Software Development, Teaching & Coaching > >> > Mobile: +54 - 11 - 4470 - 7207 > >> > email: [email protected] > >> > site: http://www.10Pines.com > >> > > >> > _______________________________________________ > >> > 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 > > > > > > > > -- > > Hernán Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 11 - 4470 - 7207 > > email: [email protected] > > site: http://www.10Pines.com > > > > _______________________________________________ > > 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 > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: [email protected] site: http://www.10Pines.com <http://www.10pines.com/>*
_______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
