2015-02-05 18:51 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:


On Thu, Feb 5, 2015 at 2:31 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:


2015-02-05 10:55 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
It is obviously a compromise (or a continuum) between abstractions and performance.

I agree. With a special view in that we are in a sub domain where simple things well designed (Smalltalk, that is) are amazingly good at supporting complex designs.
�

But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later.

And I like the fact that efficient code and design is often a pleasure to read and learn from :)

Now, being radical: could we get rid of pragmas ? The only reason I see to them is that they allow extension by external packages, because we can't have methods which belong to two protocols (*).

They are a Smalltalk-centric way of adding arbitrary metadata to methods; Smalltalk-centric in that a pragma is a Message instance, may be queried for senders, performed, etc, and that it can be parsed using the standard compiler (they add no new syntax).� They have been broadly used.� IME they have simplified and reduced code where ever they have been used.� They don't have to be there but they're a good thing.� Why do you want to get rid of them?

Because the "they have simplified and reduced code where ever they have been used" is wrong. I just have to give you a counter example:

One of the uses of pragmas is associating methods containing Gui commands or settings to specific objects. Based on an object inspected or selected, you search among all its methods the ones containing a specific pragma (and you order them by a parameter to that pragma, if you want), and you execute that method to retrieve the objects you want (presentations, menu commands, shortcuts, you name it, I use it :)).

The code to do that is exactly as long as the one which, on the same object, retrieve all methods under a certain protocol (the latter being faster than the pragma one, to boot).

Each method is one line longer ("the pragma").

Each such method usually has in its name a copy of the pragma (gtInspectorXXX methods, I'm looking at you), because of course this is far more user friendly to indicate its purpose in the method name than in only the pragma.

(There are two more arguments for the use of pragmas in that context, one which has a direct counter-example, one which hasn't: )

Moreover, the semantic of pragmas is "interesting" to describe, and in some cases, require a good amount of dark magic about a global object listening to all methods changes and capturing (and executing) certain methods in a vague relation about when this is going to happen, or being triggered on specific system events (main menu rebuilding, anyone?). The funny thing is to see that pattern visible on a profile when loading packages (talk of a scalable approach).
�
(and yes, I'm biassed)

Then you're the right person to give me counter arguments...

(Now, I'd look differently at pragmas used for gradual typing and so on... But even for something like FFI, I'd seriously prefer to have Smalltalk calls to describe the call and its arguments than a kind of script hidden inside pragmas, just for the discoverability and because it makes one less idiom to deal with)

Thierry

(Look. I started using Smalltalk in 1992... and up to your description, I wasn't aware pragmas were supposed to follow message syntax ;) Thanks for the explanation, by the way)