Pharo-users

By thread

pharo-users@lists.pharo.org

50345 messages

Re: [Pharo-users] funny idea Symbol vs. Selector

by Hernan Wilkinson

On Thu, Aug 26, 2010 at 2:02 PM, Marcin Tustin <mm3(a)zepler.net> wrote: > Uniformity is when we represent our various significands using the same > data type > well... I don't agree... starting from the fact that there are no data types in the object paradigm, just objects. > (in smalltalk using objects with the same protocol). For example, this > allows us to treat all things in our image as objects, which gives us the > flexibility to do everything in the object protocol to every kind of thing, > without having to decide that we do only some things to classes, only other > things to objects, and only other things again to constants (as in Java). > sorry, I don't understand. > > This change will introduce heterogeneity, which prevents us using the (now > two) things in the same way. > but, for me, a symbol is not a selector. What is the meaning of asking a selector for its size? for me makes more sense to ask the selector's name for its size. what is the meaning of asking a symbol for the number of arguments? if that symbol does not represent a selector there is no reason for the symbol to respond that question. > The reason to do this is if it would be a category error to do symbol > operations on a selector, as it locks us into a particular view of the way > the world should work, which is what the designers of java did when they > posited classes, objects, and constants as being entirely separate. > I dont understand if this is good or bad for you... for me the separation that java does with object, classes and data types is a mess, it is just not uniform, I prefer the smalltalk way :-) > This has the "advantage" that you can't accidentally put a constant in an > array, for example, because they wanted to restrict flexibility, in order to > protect users from mistakes. > I never made that mistake in Smalltalk and Smalltalk does not prevent me for that... > > I don't see a risk of our current approach causing errors, and I don't see > that it creates unnecessary complexity, so I am confused as to why this > change is desirable. > ok, we don't have to agree, but just answer yourself this question: the proposed change is more cohesive or not? and remember that more cohesive objects means more simplicity and uniformity... if you don't agree that cohesion implies that, well.... we should be discussing other things first :-) > > On Thu, Aug 26, 2010 at 5:52 PM, Hernan Wilkinson < > hernan.wilkinson(a)10pines.com> wrote: > >> an optimisation? for me this change looks for exactly what you plea, >> simplicity and uniformity... at the end this change makes symbol and >> selector more cohesive, and we all know that the more cohesive an object is >> the more simply and uniform it is, because it represents just one thing, no >> like symbols now that they can be symbols or selectors (therefore they are >> not as cohesive as having two different abstractions) and we, human, have to >> decide what they are instead of letting the objects decide... >> >> >> On Thu, Aug 26, 2010 at 8:43 AM, Marcin Tustin <mm3(a)zepler.net> wrote: >> >>> 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 < >>> hernan.wilkinson(a)10pines.com> 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 <siguctua(a)gmail.com>wrote: >>>> >>>>> On 26 August 2010 04:09, Hernan Wilkinson < >>>>> hernan.wilkinson(a)10pines.com> wrote: >>>>> > >>>>> > >>>>> > On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com> >>>>> wrote: >>>>> >> >>>>> >> On 25 August 2010 23:08, Hernan Wilkinson < >>>>> hernan.wilkinson(a)10pines.com> >>>>> >> wrote: >>>>> >> > >>>>> >> > >>>>> >> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko < >>>>> siguctua(a)gmail.com> >>>>> >> > wrote: >>>>> >> >> >>>>> >> >> On 25 August 2010 21:11, Hernan Wilkinson >>>>> >> >> <hernan.wilkinson(a)10pines.com> >>>>> >> >> 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 >>>>> >> >> > <stephane.ducasse(a)inria.fr> 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 <stephane.ducasse(a)inria.fr>: >>>>> >> >> >> >> 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 >>>>> >> >> >> >>> Pharo-users(a)lists.gforge.inria.fr >>>>> >> >> >> >>> >>>>> >> >> >> >>> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> _______________________________________________ >>>>> >> >> >> >> Pharo-users mailing list >>>>> >> >> >> >> Pharo-users(a)lists.gforge.inria.fr >>>>> >> >> >> >> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >> >> >> >> >>>>> >> >> >> > >>>>> >> >> >> > _______________________________________________ >>>>> >> >> >> > Pharo-users mailing list >>>>> >> >> >> > Pharo-users(a)lists.gforge.inria.fr >>>>> >> >> >> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> _______________________________________________ >>>>> >> >> >> Pharo-users mailing list >>>>> >> >> >> Pharo-users(a)lists.gforge.inria.fr >>>>> >> >> >> >>>>> 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: hernan.wilkinson(a)10Pines.com >>>>> >> >> > site: http://www.10Pines.com <http://www.10pines.com/> >>>>> >> >> > >>>>> >> >> > _______________________________________________ >>>>> >> >> > Pharo-users mailing list >>>>> >> >> > Pharo-users(a)lists.gforge.inria.fr >>>>> >> >> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >> >> > >>>>> >> >> > >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> -- >>>>> >> >> Best regards, >>>>> >> >> Igor Stasenko AKA sig. >>>>> >> >> >>>>> >> >> _______________________________________________ >>>>> >> >> Pharo-users mailing list >>>>> >> >> Pharo-users(a)lists.gforge.inria.fr >>>>> >> >> >>>>> 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: hernan.wilkinson(a)10Pines.com >>>>> >> > site: http://www.10Pines.com <http://www.10pines.com/> >>>>> >> > >>>>> >> > _______________________________________________ >>>>> >> > Pharo-users mailing list >>>>> >> > Pharo-users(a)lists.gforge.inria.fr >>>>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >> > >>>>> >> > >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Best regards, >>>>> >> Igor Stasenko AKA sig. >>>>> >> >>>>> >> _______________________________________________ >>>>> >> Pharo-users mailing list >>>>> >> Pharo-users(a)lists.gforge.inria.fr >>>>> >> 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: hernan.wilkinson(a)10Pines.com >>>>> > site: http://www.10Pines.com <http://www.10pines.com/> >>>>> > >>>>> > _______________________________________________ >>>>> > Pharo-users mailing list >>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-users mailing list >>>>> Pharo-users(a)lists.gforge.inria.fr >>>>> 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: hernan.wilkinson(a)10Pines.com >>>> site: http://www.10Pines.com <http://www.10pines.com/>* >>>> >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >>>> >>> >>> >>> -- >>> Marcin Tustin >>> Mobile: 07773787105 >>> Office: 020 3400 3259 >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> 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: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com <http://www.10pines.com/>* >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> > > > -- > Marcin Tustin > Mobile: 07773787105 > Office: 020 3400 3259 > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > 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: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 26, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Marcin Tustin

Uniformity is when we represent our various significands using the same data type (in smalltalk using objects with the same protocol). For example, this allows us to treat all things in our image as objects, which gives us the flexibility to do everything in the object protocol to every kind of thing, without having to decide that we do only some things to classes, only other things to objects, and only other things again to constants (as in Java). This change will introduce heterogeneity, which prevents us using the (now two) things in the same way. The reason to do this is if it would be a category error to do symbol operations on a selector, as it locks us into a particular view of the way the world should work, which is what the designers of java did when they posited classes, objects, and constants as being entirely separate. This has the "advantage" that you can't accidentally put a constant in an array, for example, because they wanted to restrict flexibility, in order to protect users from mistakes. I don't see a risk of our current approach causing errors, and I don't see that it creates unnecessary complexity, so I am confused as to why this change is desirable. On Thu, Aug 26, 2010 at 5:52 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > an optimisation? for me this change looks for exactly what you plea, > simplicity and uniformity... at the end this change makes symbol and > selector more cohesive, and we all know that the more cohesive an object is > the more simply and uniform it is, because it represents just one thing, no > like symbols now that they can be symbols or selectors (therefore they are > not as cohesive as having two different abstractions) and we, human, have to > decide what they are instead of letting the objects decide... > > > On Thu, Aug 26, 2010 at 8:43 AM, Marcin Tustin <mm3(a)zepler.net> wrote: > >> 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 < >> hernan.wilkinson(a)10pines.com> 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 <siguctua(a)gmail.com>wrote: >>> >>>> On 26 August 2010 04:09, Hernan Wilkinson < >>>> hernan.wilkinson(a)10pines.com> wrote: >>>> > >>>> > >>>> > On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com> >>>> wrote: >>>> >> >>>> >> On 25 August 2010 23:08, Hernan Wilkinson < >>>> hernan.wilkinson(a)10pines.com> >>>> >> wrote: >>>> >> > >>>> >> > >>>> >> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <siguctua(a)gmail.com >>>> > >>>> >> > wrote: >>>> >> >> >>>> >> >> On 25 August 2010 21:11, Hernan Wilkinson >>>> >> >> <hernan.wilkinson(a)10pines.com> >>>> >> >> 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 >>>> >> >> > <stephane.ducasse(a)inria.fr> 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 <stephane.ducasse(a)inria.fr>: >>>> >> >> >> >> 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 >>>> >> >> >> >>> Pharo-users(a)lists.gforge.inria.fr >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> _______________________________________________ >>>> >> >> >> >> Pharo-users mailing list >>>> >> >> >> >> Pharo-users(a)lists.gforge.inria.fr >>>> >> >> >> >> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >> >> >> >> >>>> >> >> >> > >>>> >> >> >> > _______________________________________________ >>>> >> >> >> > Pharo-users mailing list >>>> >> >> >> > Pharo-users(a)lists.gforge.inria.fr >>>> >> >> >> > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> _______________________________________________ >>>> >> >> >> Pharo-users mailing list >>>> >> >> >> Pharo-users(a)lists.gforge.inria.fr >>>> >> >> >> >>>> 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: hernan.wilkinson(a)10Pines.com >>>> >> >> > site: http://www.10Pines.com <http://www.10pines.com/> >>>> >> >> > >>>> >> >> > _______________________________________________ >>>> >> >> > Pharo-users mailing list >>>> >> >> > Pharo-users(a)lists.gforge.inria.fr >>>> >> >> > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >> >> > >>>> >> >> > >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> -- >>>> >> >> Best regards, >>>> >> >> Igor Stasenko AKA sig. >>>> >> >> >>>> >> >> _______________________________________________ >>>> >> >> Pharo-users mailing list >>>> >> >> Pharo-users(a)lists.gforge.inria.fr >>>> >> >> 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: hernan.wilkinson(a)10Pines.com >>>> >> > site: http://www.10Pines.com <http://www.10pines.com/> >>>> >> > >>>> >> > _______________________________________________ >>>> >> > Pharo-users mailing list >>>> >> > Pharo-users(a)lists.gforge.inria.fr >>>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >> > >>>> >> > >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Best regards, >>>> >> Igor Stasenko AKA sig. >>>> >> >>>> >> _______________________________________________ >>>> >> Pharo-users mailing list >>>> >> Pharo-users(a)lists.gforge.inria.fr >>>> >> 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: hernan.wilkinson(a)10Pines.com >>>> > site: http://www.10Pines.com <http://www.10pines.com/> >>>> > >>>> > _______________________________________________ >>>> > Pharo-users mailing list >>>> > Pharo-users(a)lists.gforge.inria.fr >>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> 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: hernan.wilkinson(a)10Pines.com >>> site: http://www.10Pines.com <http://www.10pines.com/>* >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >> >> >> -- >> Marcin Tustin >> Mobile: 07773787105 >> Office: 020 3400 3259 >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> 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: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 26, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Hernan Wilkinson

an optimisation? for me this change looks for exactly what you plea, simplicity and uniformity... at the end this change makes symbol and selector more cohesive, and we all know that the more cohesive an object is the more simply and uniform it is, because it represents just one thing, no like symbols now that they can be symbols or selectors (therefore they are not as cohesive as having two different abstractions) and we, human, have to decide what they are instead of letting the objects decide... On Thu, Aug 26, 2010 at 8:43 AM, Marcin Tustin <mm3(a)zepler.net> wrote: > 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 < > hernan.wilkinson(a)10pines.com> 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 <siguctua(a)gmail.com>wrote: >> >>> On 26 August 2010 04:09, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >>> wrote: >>> > >>> > >>> > On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >> >>> >> On 25 August 2010 23:08, Hernan Wilkinson < >>> hernan.wilkinson(a)10pines.com> >>> >> wrote: >>> >> > >>> >> > >>> >> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <siguctua(a)gmail.com> >>> >> > wrote: >>> >> >> >>> >> >> On 25 August 2010 21:11, Hernan Wilkinson >>> >> >> <hernan.wilkinson(a)10pines.com> >>> >> >> 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 >>> >> >> > <stephane.ducasse(a)inria.fr> 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 <stephane.ducasse(a)inria.fr>: >>> >> >> >> >> 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 >>> >> >> >> >>> Pharo-users(a)lists.gforge.inria.fr >>> >> >> >> >>> >>> >> >> >> >>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> _______________________________________________ >>> >> >> >> >> Pharo-users mailing list >>> >> >> >> >> Pharo-users(a)lists.gforge.inria.fr >>> >> >> >> >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > _______________________________________________ >>> >> >> >> > Pharo-users mailing list >>> >> >> >> > Pharo-users(a)lists.gforge.inria.fr >>> >> >> >> > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >>> >> >> >> >>> >> >> >> _______________________________________________ >>> >> >> >> Pharo-users mailing list >>> >> >> >> Pharo-users(a)lists.gforge.inria.fr >>> >> >> >> >>> 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: hernan.wilkinson(a)10Pines.com >>> >> >> > site: http://www.10Pines.com <http://www.10pines.com/> >>> >> >> > >>> >> >> > _______________________________________________ >>> >> >> > Pharo-users mailing list >>> >> >> > Pharo-users(a)lists.gforge.inria.fr >>> >> >> > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Best regards, >>> >> >> Igor Stasenko AKA sig. >>> >> >> >>> >> >> _______________________________________________ >>> >> >> Pharo-users mailing list >>> >> >> Pharo-users(a)lists.gforge.inria.fr >>> >> >> 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: hernan.wilkinson(a)10Pines.com >>> >> > site: http://www.10Pines.com <http://www.10pines.com/> >>> >> > >>> >> > _______________________________________________ >>> >> > Pharo-users mailing list >>> >> > Pharo-users(a)lists.gforge.inria.fr >>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Igor Stasenko AKA sig. >>> >> >>> >> _______________________________________________ >>> >> Pharo-users mailing list >>> >> Pharo-users(a)lists.gforge.inria.fr >>> >> 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: hernan.wilkinson(a)10Pines.com >>> > site: http://www.10Pines.com <http://www.10pines.com/> >>> > >>> > _______________________________________________ >>> > Pharo-users mailing list >>> > Pharo-users(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> 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: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com <http://www.10pines.com/>* >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> > > > -- > Marcin Tustin > Mobile: 07773787105 > Office: 020 3400 3259 > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > 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: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 26, 2010

Re: [Pharo-users] [Pharo-project] Fwd: Alien install issue?

by Marcin Tustin

In that case, it would appear that for whatever reason, Noury and I have images with a smaller Special Objects Array than you. Could you check if that is correct, or if for whatever reason, the packages you are installing, are not looking for Alien to be inserted at slot 53? On Thu, Aug 26, 2010 at 3:24 PM, Luc Fabresse <luc.fabresse(a)mines-douai.fr>wrote: > Hi all, > > I had no problem to install Alien on Pharo 1.1 with ConfigurationOfAlien: > > Gofer new > squeaksource: 'Alien'; > package: 'ConfigurationOfAlien'; > load. > > ((Smalltalk at: #ConfigurationOfAlien) project version: 'Pharo 1.1') load: > {'Core' . 'Tests' . 'LibC'. 'MacOSX'} > > > All 40 tests are green. > > Here the version number of the installed packages: > - ConfigurationOfAlien-KenTreis.26 > - Alien-Core-JoachimGeidel.64 > > - Alien-CoreTest-F_Olivero.22 > - Alien-Examples-F_Olivero.2 > - Alien-LibC-mha.9 > - Alien-MacOSX-AppKit-John_M_McIntosh.1 > - Alien-MacOSX-Core-John_M_McIntosh.2 > - Alien-MacOSX-Examples-John_M_McIntosh.1 > - Alien-Prereqs-KenTreis.5 > > Luc > > > Le 26 aoÃ»t 10 Ã 15:41, Marcin Tustin a Ã©crit : > > > Thanks. I won't actually have a chance to deal with this until the weekend >> after next, but if no-one else has, I will try to submit an update for the >> installer. >> >> On Thu, Aug 26, 2010 at 2:38 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> >> wrote: >> It seems that the ConfigurationOfAlien is broken. >> >> I tried on a Pharo-1.1-11411-dev10.07.01 image and got the same failure. >> It does not seem to load the most recent packages. >> >> I then loaded the packages one by one using the monticello repository >> browser >> And all tests are green (on Mac). >> >> Packages in load order: >> Alien-Prereqs-KenTreis.5 >> Alien-Core-JoachimGeidel.64 >> Alien-CoreTest-F_Olivero.22 >> Alien-Examples-F_Olivero.2 >> Alien-LibC-mha.9 >> Alien-MacOSX-AppKit-John_M_McIntosh.1 >> Alien-MacOSX-Core-John_M_McIntosh.2 >> >> Noury >> >> On 26 aoÃ»t 2010, at 15:07, Noury Bouraqadi wrote: >> >> > Hi, >> > >> > Strange. I thought we already fixed this pb. >> > I'll look at it. >> > >> > Noury >> > On 25 aoÃ»t 2010, at 19:14, John M McIntosh wrote: >> > >> >> >> >> >> >> Begin forwarded message: >> >> >> >>> From: Marcin Tustin <mm3(a)zepler.net> >> >>> Date: August 25, 2010 2:31:16 AM PDT >> >>> To: John McIntosh <johnmci(a)smalltalkconsulting.com> >> >>> Cc: A friendly place where any question about pharo is welcome < >> pharo-users(a)lists.gforge.inria.fr>, pharo-dev(a)lists.gforge.inria.fr >> >>> Subject: Re: [Pharo-users] Invoking external processes/IPC >> >>> >> >>> I'm not sure that I would class the fact that Alien wants the Special >> Objects Array to be bigger than it actually is to be a mere installation >> issue. >> >>> >> >>> On Wed, Aug 25, 2010 at 10:13 AM, John McIntosh < >> johnmci(a)smalltalkconsulting.com> wrote: >> >>> Ask on the Pharo list for help or instruction on loading alien into >> pharo, I didn't write any of the loader code so I can't deal with the fact >> it may or may not be broken. >> >>> >> >>> Sent from my iPad >> >>> >> >>> On 2010-08-25, at 1:30 AM, Marcin Tustin <mm3(a)zepler.net> wrote: >> >>> >> >>>> John, >> >>>> >> >>>> Do you have any intention of commenting on this, even to confirm that >> you are content for Alien to be incompatible with current versions of Pharo? >> >>>> >> >>>> Marcin >> >>>> >> >>>> On Mon, Aug 23, 2010 at 11:15 PM, Marcin Tustin <mm3(a)zepler.net> >> wrote: >> >>>> John, >> >>>> >> >>>> That is the installation recipe I was following, as should have been >> apparent from my description of the process followed given in my previous >> email. My problem occurred on the first step after loading the >> ConfigurationOfAlien package. >> >>>> >> >>>> For completeness, I tried loading ConfigurationOfAlien using Gofer, >> and the exact same thing occurred. I also note that Gofer>>addPackage is >> deprecated. >> >>>> >> >>>> Marcin >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Mon, Aug 23, 2010 at 10:40 PM, John M McIntosh < >> johnmci(a)smalltalkconsulting.com> wrote: >> >>>> LIkely the installation process is wrong, look at the >> http://squeaksource.com/@EGv-75Ct7JEKFz5m/rnvjMef8 >> >>>> and follow the instructions for installing there. >> >>>> >> >>>> On 2010-08-23, at 2:08 PM, Marcin Tustin wrote: >> >>>> >> >>>>> Following Mariano's advice, I just tried installing Alien (using >> Pharo-1.1-11406-rc3 with the Seaside RC3 image; this is a sane version, not >> affected by previous package loading problems). >> >>>>> >> >>>>> I loaded ConfigurationOfAlien (ConfigurationOfAlien-KenTreis.26) >> using Monticello, then executed ConfigurationOfAlien loadCore (as per the >> instructions). That resulted in an error: >> 'SystemDictionary>>recreateSpecialObjectsArray appears incompatible' raised >> from ensureInSpecialObjectsArray. The cause appears to be that Alien wants >> to be in the special objects array at 53, but the array is created to be >> size 50. >> >>>>> >> >>>>> Proceeding through the error results in the predictable subscript >> out of bounds error. >> >>>>> >> >>>>> running loadCore once more (second time) does the same thing. Doing >> it a third time results in a message not understood >> 'initScannerForTokenization' from Parser>>ParseSelector:. >> >>>>> >> >>>>> Any ideas? >> >>>>> >> >>>>> >> >>>>> On Mon, Aug 23, 2010 at 8:41 PM, Marcin Tustin <mm3(a)zepler.net> >> wrote: >> >>>>> Mariano, >> >>>>> >> >>>>> Thanks for this. I belive CommandShell depends on OSProcess. I am >> using windows, so I guess neither is a runner anyway. I'll try FFI/AlienFFI. >> >>>>> >> >>>>> Marcin >> >>>>> >> >>>>> >> >>>>> On Mon, Aug 23, 2010 at 8:19 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>>>> >> >>>>> >> >>>>> On Mon, Aug 23, 2010 at 7:45 PM, Marcin Tustin <mm3(a)zepler.net> >> wrote: >> >>>>> Hi all, >> >>>>> >> >>>>> I'm an occasional squeak/pharo dabbler, and I'm wondering what the >> recommended way of interacting with external processes is these days? >> >>>>> >> >>>>> Should I go through the process of getting all the VMMaker and >> OSProcess stuff, and build the OSProcess plugin, or is there some other way >> in Pharo to interact with the OS environment? >> >>>>> >> >>>>> >> >>>>> Hi. Which OS are you? because I think OSProcess is not working on >> Windows. And I also think there are binaries for it, so you don't need to >> generate .c from VMMaker neither compile c code to binary. >> >>>>> But I may be wrong. >> >>>>> >> >>>>> CommandShell ? >> >>>>> >> >>>>> Maybe using normal FFI or AlienFFI? They will let you invoke shared >> libraries of the OS from Pharo. >> >>>>> >> >>>>> Alternatively, are people doing something (easy) with IPC mechanisms >> like named sockets or TCP streams? >> >>>>> >> >>>>> The "project" I'm working on is putting figlet on a website, just >> for fun. >> >>>>> >> >>>>> Marcin >> >>>>> >> >>>>> -- >> >>>>> Marcin Tustin >> >>>>> Mobile: 07773787105 >> >>>>> Office: 020 3400 3259 >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Pharo-users mailing list >> >>>>> Pharo-users(a)lists.gforge.inria.fr >> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Pharo-users mailing list >> >>>>> Pharo-users(a)lists.gforge.inria.fr >> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Marcin Tustin >> >>>>> Mobile: 07773787105 >> >>>>> Office: 020 3400 3259 >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Marcin Tustin >> >>>>> Mobile: 07773787105 >> >>>>> Office: 020 3400 3259 >> >>>> >> >>>> -- >> >>>> >> =========================================================================== >> >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> >>>> Corporate Smalltalk Consulting Ltd. >> http://www.smalltalkconsulting.com >> >>>> >> =========================================================================== >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Marcin Tustin >> >>>> Mobile: 07773787105 >> >>>> Office: 020 3400 3259 >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Marcin Tustin >> >>>> Mobile: 07773787105 >> >>>> Office: 020 3400 3259 >> >>> >> >>> >> >>> >> >>> -- >> >>> Marcin Tustin >> >>> Mobile: 07773787105 >> >>> Office: 020 3400 3259 >> >> >> >> -- >> >> >> =========================================================================== >> >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> >> Corporate Smalltalk Consulting Ltd. >> http://www.smalltalkconsulting.com >> >> >> =========================================================================== >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > Noury >> > >> >> Noury >> >> >> >> >> >> -- >> Marcin Tustin >> Mobile: 07773787105 >> Office: 020 3400 3259 >> > > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 26, 2010

Re: [Pharo-users] [Pharo-project] Fwd: Alien install issue?

by Marcin Tustin

Thanks. I won't actually have a chance to deal with this until the weekend after next, but if no-one else has, I will try to submit an update for the installer. On Thu, Aug 26, 2010 at 2:38 PM, Noury Bouraqadi <bouraqadi(a)gmail.com>wrote: > It seems that the ConfigurationOfAlien is broken. > > I tried on a Pharo-1.1-11411-dev10.07.01 image and got the same failure. > It does not seem to load the most recent packages. > > I then loaded the packages one by one using the monticello repository > browser > And all tests are green (on Mac). > > Packages in load order: > Alien-Prereqs-KenTreis.5 > Alien-Core-JoachimGeidel.64 > Alien-CoreTest-F_Olivero.22 > Alien-Examples-F_Olivero.2 > Alien-LibC-mha.9 > Alien-MacOSX-AppKit-John_M_McIntosh.1 > Alien-MacOSX-Core-John_M_McIntosh.2 > > Noury > > On 26 aoÃ»t 2010, at 15:07, Noury Bouraqadi wrote: > > > Hi, > > > > Strange. I thought we already fixed this pb. > > I'll look at it. > > > > Noury > > On 25 aoÃ»t 2010, at 19:14, John M McIntosh wrote: > > > >> > >> > >> Begin forwarded message: > >> > >>> From: Marcin Tustin <mm3(a)zepler.net> > >>> Date: August 25, 2010 2:31:16 AM PDT > >>> To: John McIntosh <johnmci(a)smalltalkconsulting.com> > >>> Cc: A friendly place where any question about pharo is welcome < > pharo-users(a)lists.gforge.inria.fr>, pharo-dev(a)lists.gforge.inria.fr > >>> Subject: Re: [Pharo-users] Invoking external processes/IPC > >>> > >>> I'm not sure that I would class the fact that Alien wants the Special > Objects Array to be bigger than it actually is to be a mere installation > issue. > >>> > >>> On Wed, Aug 25, 2010 at 10:13 AM, John McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >>> Ask on the Pharo list for help or instruction on loading alien into > pharo, I didn't write any of the loader code so I can't deal with the fact > it may or may not be broken. > >>> > >>> Sent from my iPad > >>> > >>> On 2010-08-25, at 1:30 AM, Marcin Tustin <mm3(a)zepler.net> wrote: > >>> > >>>> John, > >>>> > >>>> Do you have any intention of commenting on this, even to confirm that > you are content for Alien to be incompatible with current versions of Pharo? > >>>> > >>>> Marcin > >>>> > >>>> On Mon, Aug 23, 2010 at 11:15 PM, Marcin Tustin <mm3(a)zepler.net> > wrote: > >>>> John, > >>>> > >>>> That is the installation recipe I was following, as should have been > apparent from my description of the process followed given in my previous > email. My problem occurred on the first step after loading the > ConfigurationOfAlien package. > >>>> > >>>> For completeness, I tried loading ConfigurationOfAlien using Gofer, > and the exact same thing occurred. I also note that Gofer>>addPackage is > deprecated. > >>>> > >>>> Marcin > >>>> > >>>> > >>>> > >>>> > >>>> On Mon, Aug 23, 2010 at 10:40 PM, John M McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >>>> LIkely the installation process is wrong, look at the > http://squeaksource.com/@EGv-75Ct7JEKFz5m/rnvjMef8 > >>>> and follow the instructions for installing there. > >>>> > >>>> On 2010-08-23, at 2:08 PM, Marcin Tustin wrote: > >>>> > >>>>> Following Mariano's advice, I just tried installing Alien (using > Pharo-1.1-11406-rc3 with the Seaside RC3 image; this is a sane version, not > affected by previous package loading problems). > >>>>> > >>>>> I loaded ConfigurationOfAlien (ConfigurationOfAlien-KenTreis.26) > using Monticello, then executed ConfigurationOfAlien loadCore (as per the > instructions). That resulted in an error: > 'SystemDictionary>>recreateSpecialObjectsArray appears incompatible' raised > from ensureInSpecialObjectsArray. The cause appears to be that Alien wants > to be in the special objects array at 53, but the array is created to be > size 50. > >>>>> > >>>>> Proceeding through the error results in the predictable subscript out > of bounds error. > >>>>> > >>>>> running loadCore once more (second time) does the same thing. Doing > it a third time results in a message not understood > 'initScannerForTokenization' from Parser>>ParseSelector:. > >>>>> > >>>>> Any ideas? > >>>>> > >>>>> > >>>>> On Mon, Aug 23, 2010 at 8:41 PM, Marcin Tustin <mm3(a)zepler.net> > wrote: > >>>>> Mariano, > >>>>> > >>>>> Thanks for this. I belive CommandShell depends on OSProcess. I am > using windows, so I guess neither is a runner anyway. I'll try FFI/AlienFFI. > >>>>> > >>>>> Marcin > >>>>> > >>>>> > >>>>> On Mon, Aug 23, 2010 at 8:19 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >>>>> > >>>>> > >>>>> On Mon, Aug 23, 2010 at 7:45 PM, Marcin Tustin <mm3(a)zepler.net> > wrote: > >>>>> Hi all, > >>>>> > >>>>> I'm an occasional squeak/pharo dabbler, and I'm wondering what the > recommended way of interacting with external processes is these days? > >>>>> > >>>>> Should I go through the process of getting all the VMMaker and > OSProcess stuff, and build the OSProcess plugin, or is there some other way > in Pharo to interact with the OS environment? > >>>>> > >>>>> > >>>>> Hi. Which OS are you? because I think OSProcess is not working on > Windows. And I also think there are binaries for it, so you don't need to > generate .c from VMMaker neither compile c code to binary. > >>>>> But I may be wrong. > >>>>> > >>>>> CommandShell ? > >>>>> > >>>>> Maybe using normal FFI or AlienFFI? They will let you invoke shared > libraries of the OS from Pharo. > >>>>> > >>>>> Alternatively, are people doing something (easy) with IPC mechanisms > like named sockets or TCP streams? > >>>>> > >>>>> The "project" I'm working on is putting figlet on a website, just for > fun. > >>>>> > >>>>> Marcin > >>>>> > >>>>> -- > >>>>> Marcin Tustin > >>>>> Mobile: 07773787105 > >>>>> Office: 020 3400 3259 > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-users mailing list > >>>>> Pharo-users(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-users mailing list > >>>>> Pharo-users(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Marcin Tustin > >>>>> Mobile: 07773787105 > >>>>> Office: 020 3400 3259 > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Marcin Tustin > >>>>> Mobile: 07773787105 > >>>>> Office: 020 3400 3259 > >>>> > >>>> -- > >>>> > =========================================================================== > >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > >>>> Corporate Smalltalk Consulting Ltd. > http://www.smalltalkconsulting.com > >>>> > =========================================================================== > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Marcin Tustin > >>>> Mobile: 07773787105 > >>>> Office: 020 3400 3259 > >>>> > >>>> > >>>> > >>>> -- > >>>> Marcin Tustin > >>>> Mobile: 07773787105 > >>>> Office: 020 3400 3259 > >>> > >>> > >>> > >>> -- > >>> Marcin Tustin > >>> Mobile: 07773787105 > >>> Office: 020 3400 3259 > >> > >> -- > >> > =========================================================================== > >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > >> > =========================================================================== > >> > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > Noury > > > > Noury > > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 26, 2010

Re: [Pharo-users] Pharo by Example - Lights Out

by Marcus Denker

On Aug 25, 2010, at 12:43 AM, Phil Lewis wrote: > Hi, > > I'm trying to work through PBE, and have got to the LightsOut chapter. > > It appears that SimpleSwitchMorph is not part of the image. > > I found some old posts in the archive about this, but they just seemed to be mentioning something about putting a disclaimer in the book. > > Is there any way I can progress with this tutorial? > Hello, For the book, the easiest for now is to use the image that we used when writing it.... https://gforge.inria.fr/frs/download.php/27023/PBE-1.0.zip (this is linked from http://pharobyexample.org/) The problem is that we can not update the book for every release... (just wrangling with Lulu to get it into bookstores takes quite some effort and time...). We will definitly do an update at some point, but for now, using the 1.0 image with the O2 browser is the way to go. (this has the SimpleSwitchMorph, too). Of cource, this is getting older and the differences larger with every release, so we need to do a new version of the book at some point. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 26, 2010

Fwd: [Pharo-project] would be nice to have a menu item for pointTo

by Mariano Martinez Peck

There are pharo-users that also code in pharo ;) Bejamin is a good candidate :) ---------- Forwarded message ---------- From: stephane ducasse <stephane.ducasse(a)free.fr> Date: Thu, Aug 26, 2010 at 2:36 PM Subject: [Pharo-project] would be nice to have a menu item for pointTo To: "Pharo-project(a)lists.gforge.inria.fr Development" < Pharo-project(a)lists.gforge.inria.fr> so that we can select an object and invoke pointerFinder. Any taker? http://code.google.com/p/pharo/issues/detail?id=2867 Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 26, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Marcin Tustin

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 < hernan.wilkinson(a)10pines.com> 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 <siguctua(a)gmail.com>wrote: > >> On 26 August 2010 04:09, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >> wrote: >> > >> > >> > On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> On 25 August 2010 23:08, Hernan Wilkinson < >> hernan.wilkinson(a)10pines.com> >> >> wrote: >> >> > >> >> > >> >> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <siguctua(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> On 25 August 2010 21:11, Hernan Wilkinson >> >> >> <hernan.wilkinson(a)10pines.com> >> >> >> 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 >> >> >> > <stephane.ducasse(a)inria.fr> 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 <stephane.ducasse(a)inria.fr>: >> >> >> >> >> 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 >> >> >> >> >>> Pharo-users(a)lists.gforge.inria.fr >> >> >> >> >>> >> >> >> >> >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> Pharo-users mailing list >> >> >> >> >> Pharo-users(a)lists.gforge.inria.fr >> >> >> >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> >> >> >> >> >> >> > >> >> >> >> > _______________________________________________ >> >> >> >> > Pharo-users mailing list >> >> >> >> > Pharo-users(a)lists.gforge.inria.fr >> >> >> >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Pharo-users mailing list >> >> >> >> Pharo-users(a)lists.gforge.inria.fr >> >> >> >> >> 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: hernan.wilkinson(a)10Pines.com >> >> >> > site: http://www.10Pines.com <http://www.10pines.com/> >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Pharo-users mailing list >> >> >> > Pharo-users(a)lists.gforge.inria.fr >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Best regards, >> >> >> Igor Stasenko AKA sig. >> >> >> >> >> >> _______________________________________________ >> >> >> Pharo-users mailing list >> >> >> Pharo-users(a)lists.gforge.inria.fr >> >> >> 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: hernan.wilkinson(a)10Pines.com >> >> > site: http://www.10Pines.com <http://www.10pines.com/> >> >> > >> >> > _______________________________________________ >> >> > Pharo-users mailing list >> >> > Pharo-users(a)lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> >> >> >> _______________________________________________ >> >> Pharo-users mailing list >> >> Pharo-users(a)lists.gforge.inria.fr >> >> 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: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com <http://www.10pines.com/> >> > >> > _______________________________________________ >> > Pharo-users mailing list >> > Pharo-users(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> 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: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 26, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 26 August 2010 08:20, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > 2010/8/25 Igor Stasenko <siguctua(a)gmail.com>: >>> >> >> 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 > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

Aug. 26, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Hernan Wilkinson

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 <siguctua(a)gmail.com> wrote: > On 26 August 2010 04:09, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> > wrote: > > > > > > On Wed, Aug 25, 2010 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 25 August 2010 23:08, Hernan Wilkinson <hernan.wilkinson(a)10pines.com > > > >> wrote: > >> > > >> > > >> > On Wed, Aug 25, 2010 at 4:33 PM, Igor Stasenko <siguctua(a)gmail.com> > >> > wrote: > >> >> > >> >> On 25 August 2010 21:11, Hernan Wilkinson > >> >> <hernan.wilkinson(a)10pines.com> > >> >> 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 > >> >> > <stephane.ducasse(a)inria.fr> 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 <stephane.ducasse(a)inria.fr>: > >> >> >> >> 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 > >> >> >> >>> Pharo-users(a)lists.gforge.inria.fr > >> >> >> >>> > >> >> >> >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> >> >> > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Pharo-users mailing list > >> >> >> >> Pharo-users(a)lists.gforge.inria.fr > >> >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> >> >> > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > Pharo-users mailing list > >> >> >> > Pharo-users(a)lists.gforge.inria.fr > >> >> >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Pharo-users mailing list > >> >> >> Pharo-users(a)lists.gforge.inria.fr > >> >> >> 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: hernan.wilkinson(a)10Pines.com > >> >> > site: http://www.10Pines.com > >> >> > > >> >> > _______________________________________________ > >> >> > Pharo-users mailing list > >> >> > Pharo-users(a)lists.gforge.inria.fr > >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Best regards, > >> >> Igor Stasenko AKA sig. > >> >> > >> >> _______________________________________________ > >> >> Pharo-users mailing list > >> >> Pharo-users(a)lists.gforge.inria.fr > >> >> 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: hernan.wilkinson(a)10Pines.com > >> > site: http://www.10Pines.com > >> > > >> > _______________________________________________ > >> > Pharo-users mailing list > >> > Pharo-users(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> > > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> 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: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > 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: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 26, 2010

Jump to page: