Can I make a last plea for the simplicity and uniformity of the current model? I suspect that this change is a premature optimisation that will lose us flexibility, for no apparent benefit.
On Thu, Aug 26, 2010 at 12:28 PM, Hernan Wilkinson < [email protected]> wrote: > 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 <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 >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> 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 >> > >> > >> >> >> >> -- >> 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 > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259
_______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
