On Thu, Aug 26, 2010 at 2:02 PM, Marcin Tustin
<[hidden email]> 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
<[hidden email]> 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
<[hidden email]> 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.