2015-02-05 18:51 GMT+01:00 Eliot Miranda <eliot.mira...@gmail.com>:
>
>
> On Thu, Feb 5, 2015 at 2:31 AM, Thierry Goubier <thierry.goub...@gmail.com
> > wrote:
>
>>
>>
>> 2015-02-05 10:55 GMT+01:00 Sven Van Caekenberghe <s...@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)
