[Pharo-project] does anybody knows who is using StandardToolSet?
Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder. Stef
yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it. http://code.google.com/p/pharo/issues/detail?id=1915 On Fri, Jan 28, 2011 at 10:44 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder.
Stef
On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it.
we discussed that today. probably i will take care about it for 1.3.. not sure how soon it will be but i will :)
http://code.google.com/p/pharo/issues/detail?id=1915
On Fri, Jan 28, 2011 at 10:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder.
Stef
-- Best regards, Igor Stasenko AKA sig.
Hi, I am not sure what is the current status in this area. Could anyone provide an idea of what is the desired solution? Cheers, Doru On 28 Jan 2011, at 19:35, Igor Stasenko wrote:
On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it.
we discussed that today. probably i will take care about it for 1.3.. not sure how soon it will be but i will :)
http://code.google.com/p/pharo/issues/detail?id=1915
On Fri, Jan 28, 2011 at 10:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder.
Stef
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."
On 30 January 2011 20:30, Tudor Girba <tudor.girba@gmail.com> wrote:
Hi,
I am not sure what is the current status in this area. Could anyone provide an idea of what is the desired solution?
The idea is to get rid of ToolSet references and replace all patterns like ToolSet default foo with Smalltalk tools foo or even more extreme, leave only a message send and get rid of using globals, because it is early binding: self toolset foo where #toolset implemented in Object with ^ Smalltalt tools. The answer of 'Smalltalk tools' should be a tool registry instance. The tool registry is a system-wide object where packages can register their tools. I don't remember all of the details, but the idea, when i implemented it was following: - you registering your tool(s) by sending: Smalltalk tools addTool: myTool verb: #myTool and then you can send messages to registry directly using #myTool selector: Smalltalk tools myTool So, there will be no hardcoded set of tools in a system and therefore no need for having a class, like ToolSet, which implements a protocol for 'standard' toolset. I imagine in stripped down images, some tools can be non-existing, but some still could be there. Making tools pluggable will improve modularity.
Cheers, Doru
On 28 Jan 2011, at 19:35, Igor Stasenko wrote:
On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it.
we discussed that today. probably i will take care about it for 1.3.. not sure how soon it will be but i will :)
http://code.google.com/p/pharo/issues/detail?id=1915
On Fri, Jan 28, 2011 at 10:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder.
Stef
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
-- Best regards, Igor Stasenko AKA sig.
Thanks for the explanations, Igor. I like the direction. Cheers, Doru On 31 Jan 2011, at 03:01, Igor Stasenko wrote:
On 30 January 2011 20:30, Tudor Girba <tudor.girba@gmail.com> wrote:
Hi,
I am not sure what is the current status in this area. Could anyone provide an idea of what is the desired solution?
The idea is to get rid of ToolSet references and replace all patterns like
ToolSet default foo
with
Smalltalk tools foo
or even more extreme, leave only a message send and get rid of using globals, because it is early binding:
self toolset foo
where #toolset implemented in Object with ^ Smalltalt tools.
The answer of 'Smalltalk tools' should be a tool registry instance.
The tool registry is a system-wide object where packages can register their tools. I don't remember all of the details, but the idea, when i implemented it was following:
- you registering your tool(s) by sending:
Smalltalk tools addTool: myTool verb: #myTool
and then you can send messages to registry directly using #myTool selector:
Smalltalk tools myTool
So, there will be no hardcoded set of tools in a system and therefore no need for having a class, like ToolSet, which implements a protocol for 'standard' toolset. I imagine in stripped down images, some tools can be non-existing, but some still could be there. Making tools pluggable will improve modularity.
Cheers, Doru
On 28 Jan 2011, at 19:35, Igor Stasenko wrote:
On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it.
we discussed that today. probably i will take care about it for 1.3.. not sure how soon it will be but i will :)
http://code.google.com/p/pharo/issues/detail?id=1915
On Fri, Jan 28, 2011 at 10:44 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder.
Stef
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com "What we can governs what we wish."
The answer of 'Smalltalk tools' should be a tool registry instance.
The tool registry is a system-wide object where packages can register their tools. I don't remember all of the details, but the idea, when i implemented it was following:
- you registering your tool(s) by sending:
Smalltalk tools addTool: myTool verb: #myTool
would be good to have addTool: myTool named: #myTool kind: #codebrowser so that we can avoid to have one subclass per kind. Stef
On 31 January 2011 08:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
The answer of 'Smalltalk tools' should be a tool registry instance.
The tool registry is a system-wide object where packages can register their tools. I don't remember all of the details, but the idea, when i implemented it was following:
- you registering your tool(s) by sending:
Smalltalk tools addTool: myTool verb: #myTool
would be good to have     addTool: myTool named: #myTool kind: #codebrowser
so that we can avoid to have one subclass per kind.
can you elaborate a bit? i mean why you need to have two different keys for one tool? When you registering browser at #browser, then in this way everyone refer to it using 'Smalltalk tools browser' , and of course they expecting that given tool supports certain browser protocol, which means its already of kind of 'codebrowser'.. For cases, when you have multiple browsers installed and need to show user a choice which one to use (like standard browser vs OB one) this can be solved differently: Smalltalk tools addEntry: #availableBrowsers value: WeakSet new. Smalltalk tools availableBrowsers add: MyBrowserClass. Smalltalk tools availableBrowsers add: MyOtherBrowserClass. so, then you can enumerate available browsers by using: Smalltalk tools availableBrowsers.
Stef
-- Best regards, Igor Stasenko AKA sig.
I am not sure I understand. As far as I understand, there would be a pool of different instance variables. So, why would there be any subclassing? Cheers, Doru On 31 Jan 2011, at 08:21, Stéphane Ducasse wrote:
The answer of 'Smalltalk tools' should be a tool registry instance.
The tool registry is a system-wide object where packages can register their tools. I don't remember all of the details, but the idea, when i implemented it was following:
- you registering your tool(s) by sending:
Smalltalk tools addTool: myTool verb: #myTool
would be good to have addTool: myTool named: #myTool kind: #codebrowser
so that we can avoid to have one subclass per kind.
Stef
-- www.tudorgirba.com "Being happy is a matter of choice."
participants (4)
-
Igor Stasenko -
Mariano Martinez Peck -
Stéphane Ducasse -
Tudor Girba