I don't think that we have a problem with cohesion at present (as cohesion is not a quantity, I would not say we have more or less, but a more or less problematic situation). Cohesion does not promote uniformity. It promotes simplicity in tracking the dependencies between functions (messages) and mutable state in objects. This is a different kind of simplicity from the simplicity that having a single protocol provides us.
On Thu, Aug 26, 2010 at 6:18 PM, Hernan Wilkinson < [email protected]> wrote: > > > On Thu, Aug 26, 2010 at 2:02 PM, Marcin Tustin <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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. >>>> >>>> [snip] >>>> >>>
_______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
