On 28.04.2010 21:57, Hannes Hirzel wrote:
On 4/28/10, Henrik Sperre Johansen<[email protected]> wrote:
On 28.04.2010 17:47, Brent Pinkney wrote:
Hi all,+
Could those in the know comment on how this<...> proposal is (or is not)
consistent with the fundamental Smalltalk principles
that:
1. "an object is send a message and responds with an object"
2. there is no other "magic" in the system.
Take 15 mins to read the code dealing with Pragma preferences, and you'd
have your answer.
The short answer is no, they just provide a different way of dynamically
deciding what message you want to send.
The closest equivalent would be the logic used to decide which
ImageReadWriter subclass to actually use.
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Henry
I took your piece of advice of using 15 minutes to check out what
Pharo pragma/method annotation wise and below is what I discovered.
You might want directly to jump to the end for 3 questions
--Hannes
OK, 15 minutes
1. *snip*
8)
Yes, sorry I didn't specify which images, I assumed you knew where they
were :( (The age of the discussion can tell you one more thing: 1.0 was
in beta a looooooong time :) )
The 15 minutes were meant for understanding how using pragmas adds no
magic (at least not in the Smalltalk sense).
In:
http://forum.world.st/Fix-2329-Default-MC-Directory-Setting-td2019559.html#a2020047
,
I wrote exactly where to find the code dealing with pragma discovery
in both Pharo 1.1 and Squeak 4.1.
C. How do you want to handle the menus with pragmas? (It seems that
Pharo is not much further advanced in this area).
They are handled exactly the same way Preferences is handled.
A PragmaCollector is told to find pragmas with a specific keyword.
(#systemsettings or #worldmenu respectively for Settings and the World
menu (currently the only dynamic menu in Pharo 1.1).
For the methods discovered, you then:
- for preferences: Pass in a preference builder to the method, which can
then construct its preferences.
- for menus: Pass in a menu builder to the method, which can then
construct the menu items it needs.
To the argument "But a builder decoupled from the method provides
resistance to further change!" I say:
How is that different from any of the many methods currently expecting
as argument an instance of a class in base?
If the base classes does indeed change, what would you rather see happening?
a) An MNU or deprecated warning when trying to invoke the (now) invalid
code?
b) The code simply not doing what you expect it to? (ie. not adding menu
items etc.)
Yes, in b) you can still import old code and run it with no errors. That
does not necessarily mean it does what you wanted it to do though.
Cheers,
Henry
PS. I actually like the Squeak preference pragma. In 99% of the cases,
it is sufficient, and you can place it directly as metadata in an
existing accessor method, rather than having to define a new method
simply for defining a method whose only difference from 30 others is
what variable it stores into and reads from.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
