Recent Posts

Hi Vassili

About the characer set fix:
Wouldn’t DEFAULT_CHARSET (numeric value 1) in the call to CreateFont work just as well? Based on the docs, I expect it to figure out the correct charset behind the scenes just like #defaultCharsetId does. Then again, this being a Microsoft API I don’t expect much from this expectation. Please try if DEFAULT_CHARSET works, and if it does that would be a better solution.

I've tried DEFAULT_CHARSET and it works well for me. I guess you are right and DEFAULT_CHARSET is the best solution.

More generally about defining presenters, keep in mind that the arrangement you see in Hopscotch with Fragment and Presenter defining all those DSL/factory methods is not ideal at all. Hopscotch was written three years ago in Newspeak 1 which didn’t have mixins. My plan was to revisit the design once we had full mixin support and object literals, and with that considerably more freedom in where to put what behavior. One possible solution is to define a presenter layout as an object literal inside the #definition method, with the actual layout-defining expression contained in a method of the literal. With this, throughout the definition the receiver is not the presenter but something entirely different, and you can mix all sorts of convenience things into it. Or instead an object literal, the definition can be a nested class of a presenter.

I'm trying to imagine what that would be, and looking forward to see it implemented. But current Presenter / Fragment duo is IMO quite powerfull too.

The whole question of how to deal with extension methods/monkey patching etc. is a vexing one. Many constructs have been introduced to deal with this kind of situation. None are quite satisfactory.

Often the desire for extension methods is just for syntactic convenience, and in these situations  it is usually quite acceptable to introduce local utility methods/functions; but sometimes not, as when defining an internal DSL (which Hopscotch does). Class hierarchy inheritance can help here, but as noted above, it won't deal with data from other libraries. Not so much a problem with a single application dealing with Hopscotch, but once you try and integrate it with others, you need to be careful.

The case of platform specific extensions is again rather special. The struggle continues.

[To ensure consistent results when creating a font, do not specify OEM_CHARSET or DEFAULT_CHARSET.]

But anyway this remark in msdn documentation article does not bode well.

To ensure consistent results when creating a font, do not specify OEM_CHARSET or DEFAULT_CHARSET. 

Yes, I saw that. I hope they mean with those settings the same piece of code can display correct characters on one machine and gibberish on another, depending on the locale settings.

[in:anySatisfy:]

Hi Ryan

Adding convenience methods with class hierarchy inheritance gives me pause because other modules you work with might pass you objects of the original class.  If you mixin the classic anySatisfy: to Collection (not included in the goodthink lib), you couldn't rely on any of the collections returned from the modules that are part of the platform to respond to anySatisfy:.  

Absolutely.

I don't think recourse to marcos is needed, but rather a recognition that implicit receivers are our friends .  With implicit receivers can get you pretty close to the brevity of a convenience method if you define at the top of your module something like

in: aCollection anySatisfy: predicate = (...)

so

{1.2.3} anySatisfy: [:a | a < 2]

becomes

in: {1.2.3} anySatisfy: [:a | a < 2]

which is a perfectly reasonable cost to keep the base libraries clean.

I would agree with that. Moreover, I actually ended up with such a method on top of my module.

Code:

i18n: value <String> = (
^I18n translate: value
)

That is best available solution IMO.
But - while I agree that in:anySatisfy: is pretty close to anySatisfy: when unary message i18n becomes i18n: consequences for readability is much more visible IMHO.

Code:

label: 'someString' i18

become

Code:

label: (i18: 'someString')

for instance.

Adding convenience methods with class hierarchy inheritance gives me pause because other modules you work with might pass you objects of the original class.  If you mixin the classic anySatisfy: to Collection (not included in the goodthink lib), you couldn't rely on any of the collections returned from the modules that are part of the platform to respond to anySatisfy:.   I don't think recourse to marcos is needed, but rather a recognition that implicit receivers are our friends .  With implicit receivers can get you pretty close to the brevity of a convenience method if you define at the top of your module something like

in: aCollection anySatisfy: predicate = (...)

so

{1.2.3} anySatisfy: [:a | a < 2]

becomes

in: {1.2.3} anySatisfy: [:a | a < 2]

which is a perfectly reasonable cost to keep the base libraries clean.

[translate:]

Hi Gilad

I've been thinking about a related issue: so-called "convenience methods".  These turninto "nuisance methods" if they get into the base platform, because they create bloat and new users are confronted with a huge API that they must sort through. On the other hand, these methods are convenient.

One approach is to use class hierarchy inheritance. If you want twenty additional methods in the collection hierarchy, you create a module that is designed to act as a mixin that will be applied to the existing collections module, and use that.

I think part of my examples not simply related but exactly concern problem of "convenience methods". Incidentally I've came up with different conclusion. Maybe I just do not see some obvious solution.
I'll try to clarify my opinion.

I'll again use my "real life" scenario as example. So I'm adding some internalization to my application. It's boil down to Class I18n with method translate: aValue <String>
On this point in full squeak programming mode I would like to add "convenience method" i18n to String. i.e.

Code:

i18n <String> = (
    ^I18n translate: self
)

That method is convenient in usage and very similar to such a "convenient methods" of squeak base as asPoscript, asAlien, asURI and so on.
But adding such a "convenient method" is not only a badthing but just does not works for me in Newspeak programming mode. The freshly added to String "convenient method" will be absent in deployment image and raise DNU in deployed application.
(And BTW I would say I understand and agree that it is right and good from many points of view)

But how ability to create mixin - say InternalizationAwareString - with such a method would help me to sugar code in that situation?

I basically have 3 patterns of usage of message i18n

Code:

'someStringLiteral' i18n
someMethodInMyModuleReturningString i18n
someMethodFromBaseClassReturningString i18n

Literal and methods of external class will return ByteString, unaware of i18n.
and someMethodInMyModuleReturningString would look like

Code:

someMethodInMyModuleReturningString = (
    ^InternalizationAwareString fromString: 'someStringLiteral'
)

and that doesn't loook more convenient then original I18n translate: self.

Actually while I may imagine some scenarios where class inheritance approach may help to emulate "convenient methods" usage pattern - as a rule, I think such scenario as in my case is prevailed. (BTW another my case - with tooltips - is very similar. In that case I would like to add convenience method to Fragment). And for such a scenario mixins IMO are not relevant.

I'm not quite sure, but I guess relevant would be some variation of macro system as in Lisp world.
I imagine macro section in top level class declaration which stated something like:

Code:

Anything i18n => (I18n translate: Anything) .
Anything tooltip: aStr => Anything addDecorator: (TooltipAgent new tooltip: aStr) .

And i result of such declaration inside my module Parser substitute left part of macro statement with right one.
so

Code:

button: 'someLabel' i18n action: [nothing]

would be substituted by

Code:

button: (I18n translate: 'someLabel') action: [nothing]

Nothing did clutter the base system. All works in deployed applpication. Convenience is at upmost level.
Readability hopefully did improved too.
What a dream

Hi Vadim,

I went ahead and added Sudoku to our development repo. I added a copyright in your name, and an MIT license notice. The files are available at http://bracha.org/Sudoku/ (so if you refine it further, you'll have the copyright/license stuff in there).
Thanks!

Thank you, Gilad.

Hi Vadim,

I went ahead and added Sudoku to our development repo. I added a copyright in your name, and an MIT license notice. The files are available at http://bracha.org/Sudoku/ (so if you refine it further, you'll have the copyright/license stuff in there).
Thanks!

[To ensure consistent results when creating a font, do not specify OEM_CHARSET or DEFAULT_CHARSET.]

About the characer set fix:

Wouldn’t DEFAULT_CHARSET (numeric value 1) in the call to CreateFont work just as well? Based on the docs, I expect it to figure out the correct charset behind the scenes just like #defaultCharsetId does. Then again, this being a Microsoft API I don’t expect much from this expectation. Please try if DEFAULT_CHARSET works, and if it does that would be a better solution.

Hi, Vassili

I don't remember exactly if I have tried DEFAULT_CHARSET, will try it on this weekend.
But anyway this remark in msdn documentation article does not bode well.

To ensure consistent results when creating a font, do not specify OEM_CHARSET or DEFAULT_CHARSET. 

Wow, that was some catching up to do.

About the characer set fix:

Wouldn’t DEFAULT_CHARSET (numeric value 1) in the call to CreateFont work just as well? Based on the docs, I expect it to figure out the correct charset behind the scenes just like #defaultCharsetId does. Then again, this being a Microsoft API I don’t expect much from this expectation. Please try if DEFAULT_CHARSET works, and if it does that would be a better solution.

More generally, this still doesn’t address the fundamental flaw of the whole system. We shouldn’t be working with ASCII text and worrying about charsets to begin with. We have to because we build on top of Squeak and Squeak can’t handle Unicode. The plan at the time was to eventually move onto another implementation substrate, use Unicode for text and be happy. One of those best-laid schemes of mice and men.

Regarding tooltips specifically, they are not a Windows-specific facility, so there’s nothing wrong with them being in the core API. If the target platform doesn't support them in the end, it's not a big deal. There is a difference between true platform-specific concepts, like the FirstResponder of Cocoa, which an application may need access to to behave correctly, and an embellishment such as a tooltip. If an application needs tooltips to be usable, something is wrong about its design.

More generally about defining presenters, keep in mind that the arrangement you see in Hopscotch with Fragment and Presenter defining all those DSL/factory methods is not ideal at all. Hopscotch was written three years ago in Newspeak 1 which didn’t have mixins. My plan was to revisit the design once we had full mixin support and object literals, and with that considerably more freedom in where to put what behavior. One possible solution is to define a presenter layout as an object literal inside the #definition method, with the actual layout-defining expression contained in a method of the literal. With this, throughout the definition the receiver is not the presenter but something entirely different, and you can mix all sorts of convenience things into it. Or instead an object literal, the definition can be a nested class of a presenter.

Also, I don’t think your #fragment:tooltip: is all that bad. Given that we are not able to smuggle new API into the base presenter completely unnoticed, I think it’s good to have it clearly separated from the base. It might not be the most concise syntax, but it’s a compromise for a good cause. Those who try to curve-fit their syntax too much end up with Ruby or worse.