> > > is so much more "complicated" than > > ------------------- > Editor class>>blinkingCursor > <preference: 'Blinking Text Cursor' > category: 'Morphic' > description: 'When true, the text cursor will blink.' > type: #Boolean> > ^ BlinkingCursor ifNil: [ true ] > ------------------- > > Well the former is executable and must be executable. The latter is not > necessarily executable (but its good if it is, because one can locate the > code that processes the specification) . So they're the same on that level. > But the former can only be executable and isn't separated from the processing > code, whereas the latter is separated.
Yes this is clear we got that discussion long time ago and we are aware of the pros and the cons. At least as a language designer expert this is obvious to me. Now I do not want to argue again. The goal of setting is to have settings totally out of the code and only make sense in presence of an interpreter of them. So... > The former also only works in context (aBuilder) whereas the latter stands > alone, and this ability to stand alone, as a specification, loosely coupled > to the settings maintennance system is one thing that makes it simpler. It > also clearly states the default value which the former doesn't. So I find > the latter significantly easier to understand, and given I understand the > method annotation system I find the mechanics not that much more complicated > than the former's. We all understand perform: right? Yes now the key dimension is whether your vocabulary is fixed or not. When you have a fixed vocabulary then this is clear that the declarative syntax is the winner and the other one does not make sense. But for preferences it does not work. or you should have a much more lengthly key and interpret the arguments. > You prefer UI+domain mixing, we prefer UI separated from domain. > > I see the opposite. I see good separation in the latter example but I don't > see the separation in the former. And BTW this is me trying to think > critically, trying to keep happy feet in both the Pharo and Squeak (and eToys > and Cuis and ....) camps, not trying to be tribal. Apologies in advance if > expressing a contradictory view is taken as offensive. I will not add more. I think that we should favor declarative syntax as much as we can but not more. Stef _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
