Re: [Pharo-users] Rewriting question

[Nicolai Hess]

2017-06-10 21:16 GMT+02:00 werner kassens :

> On 06/10/2017 04:07 PM, werner kassens wrote:
>
>> On 06/10/2017 03:37 PM, werner kassens wrote:
>>
>>> Hi,
>>>
>>> i have a private rewriting rule. unfortunately it shows up in the lower
>>> pane of the SystemBrowser which makes no sense at all, since it is not
>>> intended for use outside of the program using it. how do i make it
>>> invisible for that part of the systembrowser? and btw where are the rules
>>> collected for that part?
>>>
>>> werner
>>>
>> i should add that it only shows up after i used it.
>> werner
>>
> and i use this way:
> b:=MyRBTransformationRule new runOnEnvironment: a.
> b builder changes do:[:r|r execute].
> and afterwards MyRBTransformationRule also appears in the lower
> SystemBrowser pane if applicable.
>


Maybe all transformation rules are defaults to "visible rule classes"
(see ReRuleManager allRules)

@Yuriy
can you check
ReRuleManager classAdded: aClassAddedAnnouncement
I am not sure the (aClassAddedAnnouncement classAdded isKindOf:
RBLintRule) works as intended.

Re: [Pharo-users] Pharo6 server deployment and no home directory

[Juraj Kubelka]

Hi Holger,

I have an impression that it can be solved by using "--no-default-preferences” 
option: 
./pharo Pharo.image --no-default-preferences

Is it a good solution for you? Or do you need to load some preferences? 

Another option could be implementing an error signal, e.g., CantFindOriginError 
in the cantFindOriginError method and catch this in the GlobalIdentifier object.

Cheers,
Juraj


> El 11-06-2017, a las 11:36, Juraj Kubelka  escribió:
> 
> Hi Holger,
> 
> thanks for the report. I will resolve it soon: 
> https://pharo.fogbugz.com/f/cases/20135/Server-deployment-is-broken-due-to-GlobalIdentifier-second-report
>  
> 
>  
> 
> Cheers,
> Juraj
> 
>> El 08-06-2017, a las 17:16, Holger Freyther > > escribió:
>> 
>> 
>>> On 17. Apr 2017, at 21:30, Juraj Kubelka >> > wrote:
>>> 
>>> Hi Holger,
>> 
>> Hey Juraj!
>> 
>> 
>>> Basically it tests `FileLocator home exists`, if false, it does not touch 
>>> disk. We could also add a #disablePersistence method if necessary.
>> 
>> I thought I tested it but somehow it is broken (again)? Looks like 
>> FileLocator>>#exists fails instead of answering false? Can you reproduce it?
>> 
>> $ unset HOME
>> $ pharo ...
>> Error: Can't find the requested origin
>> UnixResolver(PlatformResolver)>>cantFindOriginError
>> [ self cantFindOriginError ] in 
>> UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ 
>> self cantFindOriginError ]
>> UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or:
>> UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:
>> UnixResolver>>home
>> [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home 
>> / '.config' ]
>> UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or:
>> UnixResolver>>preferences
>> UnixResolver(FileSystemResolver)>>resolve:
>> SystemResolver(FileSystemResolver)>>unknownOrigin:
>> SystemResolver(FileSystemResolver)>>resolve:
>> InteractiveResolver>>unknownOrigin:
>> [ self unknownOrigin: origin ] in InteractiveResolver>>resolve: in Block: [ 
>> self unknownOrigin: origin ]
>> IdentityDictionary(Dictionary)>>at:ifAbsent:
>> InteractiveResolver>>resolve:
>> FileLocator>>resolve
>> FileLocator(AbstractFileReference)>>exists
>> GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>shouldCallPreviousPersistence
>> GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure:
>> GlobalIdentifier>>ensure
>> GlobalIdentifier class>>initializeUniqueInstance
>> GlobalIdentifier class>>uniqueInstance
>> SystemSettingsPersistence class>>resumeSystemSettings
>> [ :persistence | persistence resumeSystemSettings ] in 
>> PharoCommandLineHandler>>runPreferences in Block: [ :persistence | 
>> persistence resumeSystemSettings ...etc...
>> BlockClosure>>cull:
>> SystemDictionary(Dictionary)>>at:ifPresent:
>> SmalltalkImage>>at:ifPresent:
>> PharoCommandLineHandler>>runPreferences
>> PharoCommandLineHandler>>activate
>> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
> 

Re: [Pharo-users] How to grab a debug on Syntax Error?

[Henrik Sperre Johansen]

Depends on whether you have a SyntaxErrorNotification or a SemanticError.

For SyntaxErrorNotifications, you can wrap in a handler block raising a
debugger (and will see at which index in source the error is for).
Handling automatically is very kludgey without changes to the way
OpalCompiler fetches source, which isn't really easily available to edit and
resume from SyntaxErrorNotification handling code outside the scope of a
controlling SourceEditor.

For SemanticErrors, you're currently SOL, as they have a handling block in
the compiler, rather than being raised and, only if unhandled, use a default
action which notifies/logs dependent on whether compilation is interactive
or not.



--
View this message in context: 
http://forum.world.st/How-to-grab-a-debug-on-Syntax-Error-tp4950809p4950951.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] How to grab a debug on Syntax Error?

[Henrik Sperre Johansen]

Stephane Ducasse-3 wrote
> You get a pop up but now idea how to do anything with it. 

You're supposed to edit the invalid source code in the popup, and save it.
Then load will proceed using the corrected code.
The title / tooltip for the popup could surely use some better explaining ;)



--
View this message in context: 
http://forum.world.st/How-to-grab-a-debug-on-Syntax-Error-tp4950809p4950953.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] How to grab a debug on Syntax Error?

[Marcus Denker]

> On 12 Jun 2017, at 10:46, Henrik Sperre Johansen 
>  wrote:
> 
> Stephane Ducasse-3 wrote
>> You get a pop up but now idea how to do anything with it. 
> 
> You're supposed to edit the invalid source code in the popup, and save it.
> Then load will proceed using the corrected code.

Yes, and it even works (just tested it). It was broken for quite a long time… 
(this does not happen often, so issues with it tend to not be worked on with
priority)

> The title / tooltip for the popup could surely use some better explaining ;)
> 

There is a menu which is very hidden that has the important “debug calling 
process”.

The UI needs some improvements to guide the user better, especially as it is 
just
not every month (or even year) that one sees it…

Marcus

Re: [Pharo-users] Rewriting question

[werner kassens]

Hi Nicolai,
thanks, yes, i can see that basically more or less solves the problem i had.
werner

On 06/12/2017 09:15 AM, Nicolai Hess wrote:



2017-06-10 21:16 GMT+02:00 werner kassens >:


On 06/10/2017 04:07 PM, werner kassens wrote:

On 06/10/2017 03:37 PM, werner kassens wrote:

Hi,

i have a private rewriting rule. unfortunately it shows up
in the lower pane of the SystemBrowser which makes no
sense at all, since it is not intended for use outside of
the program using it. how do i make it invisible for that
part of the systembrowser? and btw where are the rules
collected for that part?

werner

i should add that it only shows up after i used it.
werner

and i use this way:
b:=MyRBTransformationRule new runOnEnvironment: a.
b builder changes do:[:r|r execute].
and afterwards MyRBTransformationRule also appears in the lower
SystemBrowser pane if applicable.



Maybe all transformation rules are defaults to "visible rule classes"
(see ReRuleManager allRules)

@Yuriy
can you check
ReRuleManager classAdded: aClassAddedAnnouncement
I am not sure the (aClassAddedAnnouncement classAdded isKindOf: 
RBLintRule) works as intended.

Re: [Pharo-users] Wiring objects, IoC and Service Locator

[Vitor Medina Cruz]

>
> I don't think it should. If you have a small cluster of objects where you
> can manage the dependencies yourself, you can compose larger objects from
> them and manage the dependencies the same way. By doing so, you'll get an
> object that is simpler from the outside than it's parts in the inside, and
> you'll need to solve the smaller problem again. In other words we shouldn't
> write large software, but compose large software from smaller ones. But the
> same can be done with objects (that's why I'm not a big fan of
> microservices
> despite they solve this problem similarly).
> If you have a flat structure (where objects don't form higher level
> abstractions) and everything needs to know about everything else, then the
> DI container will make it easier to work with this structure. But I don't
> think this is the right way to organize a software.


Yes, that makes sense


1. Blocks (i.e. anonymous functions) means that one needs not necessarily
> implement a /Class/ (MovieFinder), in order to vary alternative behavior,
> unlike Java (before 8).
>


2. If one does want a number of "finders" (as Classes), then one will
> typically see one "injected" (constructor or method injection), where each
> understands some common "find" message.
>


Is the real question for 2 above, "what (or who) decides" which will be
> injected?



Finder is just an illustration of the problem, that finder class can have
much more behavior in a real example, such as a DAO or a Repository would
have, and blocks could't be used properly to deal with that.

cheers,
Vitor





On Sat, Jun 10, 2017 at 8:59 AM, aryehof  wrote:

> In SmallTalk:-
>
> 1. Blocks (i.e. anonymous functions) means that one needs not necessarily
> implement a /Class/ (MovieFinder), in order to vary alternative behavior,
> unlike Java (before 8).
>
> 2. If one does want a number of "finders" (as Classes), then one will
> typically see one "injected" (constructor or method injection), where each
> understands some common "find" message.
>
> Is the real question for 2 above, "what (or who) decides" which will be
> injected?
>
>
>
> --
> View this message in context: http://forum.world.st/Wiring-
> objects-IoC-and-Service-Locator-tp4949280p4950768.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

[Pharo-users] Remote debugger: do i need identical images ?

[Steven Costiou]

Hi, 

when using the Pharo remote debugger, we have a server side (the remote
application) and a client side (the local computer used to debug). 

Apart from the remote debugger itself, do both images need to have
exactly the same code - especially the application itself - or could
they be different ? 

More specifically, to debug a program, do i need a local "clone" image
dedicated to debug the remote image ? 

Steven. 

Re: [Pharo-users] Remote debugger: do i need identical images ?

[Denis Kudriashov]

Hi.

2017-06-12 16:03 GMT+02:00 Steven Costiou :

> Hi,
>
> when using the Pharo remote debugger, we have a server side (the remote
> application) and a client side (the local computer used to debug).
>
> Apart from the remote debugger itself, do both images need to have exactly
> the same code - especially the application itself - or could they be
> different ?
>
> More specifically, to debug a program, do i need a local "clone" image
> dedicated to debug the remote image ?
>
No. Client development image not needs any code of your remote application.

Only requirement is same version of PharmIDE related projects on both
images.

Re: [Pharo-users] Remote debugger: do i need identical images ?

[Steven Costiou]

Le 2017-06-12 16:27, Denis Kudriashov a écrit :

> Hi. 
> 
> 2017-06-12 16:03 GMT+02:00 Steven Costiou :
> 
>> Hi, 
>> 
>> when using the Pharo remote debugger, we have a server side (the remote 
>> application) and a client side (the local computer used to debug). 
>> 
>> Apart from the remote debugger itself, do both images need to have exactly 
>> the same code - especially the application itself - or could they be 
>> different ? 
>> 
>> More specifically, to debug a program, do i need a local "clone" image 
>> dedicated to debug the remote image ?
> No. Client development image not needs any code of your remote application. 
> 
> Only requirement is same version of PharmIDE related projects on both images.

Thanks :) 

[Pharo-users] A question of style - pass a context or embed one?

[Tim Mackinnon]

Hi - I’m after some ideas or maybe previous examples that might guide me in the 
best approach of wrapping a low level library (essentially the Jira connector 
that Phil demo’d at Pharo days this year).

There are some low level commands that will fetch json arrays for you given a 
“lira” instance- e.g:

board := JiraBoard fromJira: jira named: ‘Project'.
sprints := board sprintsFrom: jira.

My question is related to building on top of this - and its a style question.

I want model objects that wrap the json arrays and let me navigate things a bit 
more simply, and query details more naturally - however I can’t decide whether 
my model objects should “contain” a jira when you instantiate them - which can 
be re-used for subsequent queries - OR - whether I should view jira as a from 
of context, and keep passing it to methods when I need to retrieve more 
details, or child objects?

e.g. 
myBoard := ModelBoard fromJira: jira named: ‘Project’.
mySprints := myBoard sprints. “No need to pass the jira again”.

vs.

mySprints :- myBoard sprintsIn: jira.


I’m wondering if anything might guide me one way or the other? Is one more 
tasteful/elegant than the other?

Tim

Re: [Pharo-users] A question of style - pass a context or embed one?

[Esteban A. Maringolo]

Hello Tim,

2017-06-12 16:15 GMT-03:00 Tim Mackinnon :
> Hi - I’m after some ideas or maybe previous examples that might guide me in 
> the best approach of wrapping a low level library (essentially the Jira 
> connector that Phil demo’d at Pharo days this year).
>
> There are some low level commands that will fetch json arrays for you given a 
> “lira” instance- e.g:
>
> board := JiraBoard fromJira: jira named: ‘Project'.
> sprints := board sprintsFrom: jira.
>
> My question is related to building on top of this - and its a style question.
>
> I want model objects that wrap the json arrays and let me navigate things a 
> bit more simply, and query details more naturally - however I can’t decide 
> whether my model objects should “contain” a jira when you instantiate them - 
> which can be re-used for subsequent queries - OR - whether I should view jira 
> as a from of context, and keep passing it to methods when I need to retrieve 
> more details, or child objects?
>
> e.g.
> myBoard := ModelBoard fromJira: jira named: ‘Project’.
> mySprints := myBoard sprints. “No need to pass the jira again”.
>
> vs.
>
> mySprints :- myBoard sprintsIn: jira.
>
>
> I’m wondering if anything might guide me one way or the other? Is one more 
> tasteful/elegant than the other?


I'd go for the first option. It is, every JIRA object knows the "jira"
it belongs to.

Although the second option is better for decoupling, not having to
pass objects around to obtain properties allows you to better
integrate with the tools (think GTInspector with specific inspector
for cards).

I don't understand what the "jira" is exactly, if a whole JSON object
(a Dictionary) containing everything, a connection to JIRA API, or
just the JSON object/Dictionary branch containing the attributes
specific of the "wraping" object (the board, in this case).

Regards!

Esteban A. Maringolo

Re: [Pharo-users] A question of style - pass a context or embed one?

[p...@highoctane.be]

A dynamic variable could work too.

But domain objects are somewhat hard to do in my view because we are
dealing with an API that has tons of options and customizability in its
results + people can define their own types and fields.

That's why I went for a JiraBuilder thing that has a reference to a Jira
instance.
That builder is allowing one to make higher level queries for the users
(like doing Epics, Stories, links, custom fields resolution, meta data
grabbing, prototype creation etc).

I didn't want to have an Epic class, a Story class, etc. Because my idea of
an Epic may not be your idea, so we may end up with a PluggableEpic etc and
it will never end.

My take is that it is better to use the vocabulary of the domain in the
method names but still work with dynamic structures like dictionaries and
some helpers.

I am still curious to see those domain objects because I understand that
they would ease inspection etc.

Maybe we should have a generator for these so that we can regenerate the
classes based on the metadata provided by Jira.

Phil

On Mon, Jun 12, 2017 at 9:28 PM, Esteban A. Maringolo 
wrote:

> Hello Tim,
>
> 2017-06-12 16:15 GMT-03:00 Tim Mackinnon :
> > Hi - I’m after some ideas or maybe previous examples that might guide me
> in the best approach of wrapping a low level library (essentially the Jira
> connector that Phil demo’d at Pharo days this year).
> >
> > There are some low level commands that will fetch json arrays for you
> given a “lira” instance- e.g:
> >
> > board := JiraBoard fromJira: jira named: ‘Project'.
> > sprints := board sprintsFrom: jira.
> >
> > My question is related to building on top of this - and its a style
> question.
> >
> > I want model objects that wrap the json arrays and let me navigate
> things a bit more simply, and query details more naturally - however I
> can’t decide whether my model objects should “contain” a jira when you
> instantiate them - which can be re-used for subsequent queries - OR -
> whether I should view jira as a from of context, and keep passing it to
> methods when I need to retrieve more details, or child objects?
> >
> > e.g.
> > myBoard := ModelBoard fromJira: jira named: ‘Project’.
> > mySprints := myBoard sprints. “No need to pass the jira again”.
> >
> > vs.
> >
> > mySprints :- myBoard sprintsIn: jira.
> >
> >
> > I’m wondering if anything might guide me one way or the other? Is one
> more tasteful/elegant than the other?
>
>
> I'd go for the first option. It is, every JIRA object knows the "jira"
> it belongs to.
>
> Although the second option is better for decoupling, not having to
> pass objects around to obtain properties allows you to better
> integrate with the tools (think GTInspector with specific inspector
> for cards).
>
> I don't understand what the "jira" is exactly, if a whole JSON object
> (a Dictionary) containing everything, a connection to JIRA API, or
> just the JSON object/Dictionary branch containing the attributes
> specific of the "wraping" object (the board, in this case).
>
> Regards!
>
> Esteban A. Maringolo
>
>
>

[Pharo-users] Test request

[Hilaire]

Hi,


A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do
not meet on my 12.04 config. It seems related to Cairo or FreeType. I
will likely update my system on 16.04 later this summer, but I can't
just tweak it as this is the end of the school year with several admin
tasks to conduct.

Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and
report to me any problem?

If so, here is what to do:

1. Download and unzip
https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip

2. Adjust system to 32 bits compatibility if necessary, follow
instructions at
http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1

3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the
zip file at
https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0

Does it went fine? 

Thanks

Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Test request

[john pfersich]

I followed the steps in your mail and it seems to work fine in Ubuntu 16.04
LTS, though I've never tried Dr Geo and the app is mostly in French. It's
been 47 years since I've used French extensively, so YMMV. Let you know if
I have problems.

On Mon, Jun 12, 2017 at 12:59 PM, Hilaire  wrote:

> Hi,
>
>
> A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do
> not meet on my 12.04 config. It seems related to Cairo or FreeType. I
> will likely update my system on 16.04 later this summer, but I can't
> just tweak it as this is the end of the school year with several admin
> tasks to conduct.
>
> Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and
> report to me any problem?
>
> If so, here is what to do:
>
> 1. Download and unzip
> https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip
>
> 2. Adjust system to 32 bits compatibility if necessary, follow
> instructions at
> http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1
>
> 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the
> zip file at
> https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0
>
> Does it went fine?
>
> Thanks
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Help in thinking about how to save a "program"

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
Hi Glenn,
Another very useful tool you can use to save/manipulate/store Smalltalk scripts 
is ScriptManager (http://catalog.pharo.org/catalog/project/ScriptManager).  
There are plenty of similar tools but this one is very easy to use and simple 
and has been doing the job for years for me.

hth - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Glenn Hoetker 
 To: pharo-users@lists.pharo.org 
 Sent: Sunday, June 11, 2017 7:23 PM
 Subject: [Pharo-users] Help in thinking about how to save a "program"
   
Hi all.  I’m new to Pharo and loving it.  As I transition from a text-file 
based mindset, I’m a little stuck and would appreciate help in how to think 
about a situation in a Pharonic (Pharo-ish, Pharoc?) way.
I”m crafting a short program to help me process a large text file 
(specifically: extract, sorting, and regularizing the “keyword” fields of a 
large BibTex file). Especially since I don’t really know what I’m doing, 
working in a Playground has been a great development environment.  Now that the 
program is complete (under 30 lines, wonderful), I want to be able to save it 
for future reference (and perhaps for future use).  If I’d written a shell 
script, I’d just save “fixBibDeskKeyWords.sh” to a directory. I’m not sure what 
to do in the Pharo environment, thought.
At the moment, it just lives in the Playground I’ve developed it on.  I could 
save the image and leave that Playground open, but I’m just positive that’s not 
a best practice. I also worry about what happens if I closed/cleared that 
Playground by accident.
I think I understand that, if I created a new package, I could use Monticello 
to save it to a local cache and load it into a new image whenever I needed it.  
But, given that it’s short, highly specialized and fairly linear, the idea of 
creating a “GHBibDeskStuff” package with one class (“GBibDeskKeywordFixer” 
containing a single “FixFile” method seems really heavy and awkward.
Can one save the contents of a Playground in a Pharonic way?  Is there a better 
approach?
Thank you to all involved in this wonderful programming ecosystem. I appreciate 
any advice.
Glenn
Glenn Hoetkerghoetker@me.comhttp://hoetker.faculty.asu.edu




   --- End Message ---

Re: [Pharo-users] Help in thinking about how to save a "program"

[Ben Coman]

On Mon, Jun 12, 2017 at 7:22 AM, Glenn Hoetker  wrote:

> Hi all.  I’m new to Pharo and loving it.  As I transition from a text-file
> based mindset, I’m a little stuck and would appreciate help in how to think
> about a situation in a Pharonic (Pharo-ish, Pharoc?) way.
>
> I”m crafting a short program to help me process a large text file
> (specifically: extract, sorting, and regularizing the “keyword” fields of a
> large BibTex file). Especially since I don’t really know what I’m doing,
> working in a Playground has been a great development environment.  Now that
> the program is complete (under 30 lines, wonderful), I want to be able to
> save it for future reference (and perhaps for future use).  If I’d written
> a shell script, I’d just save “fixBibDeskKeyWords.sh” to a directory. I’m
> not sure what to do in the Pharo environment, thought.
>
> At the moment, it just lives in the Playground I’ve developed it on.  I
> could save the image and leave that Playground open, but I’m just positive
> that’s not a best practice. I also worry about what happens if I
> closed/cleared that Playground by accident.
>
> I think I understand that, if I created a new package, I could use
> Monticello to save it to a local cache and load it into a new image
> whenever I needed it.  But, given that it’s short, highly specialized and
> fairly linear, the idea of creating a “GHBibDeskStuff” package with one
> class (“GBibDeskKeywordFixer” containing a single “FixFile” method seems
> really heavy and awkward.
>
> Can one save the contents of a Playground in a Pharonic way?  Is there a
> better approach?
>
> Thank you to all involved in this wonderful programming ecosystem. I
> appreciate any advice.
>

Great to hear you are enjoying Pharo.

The heavy part of saving to disk as a Monticello package is an optional
secondary step, but to make you code "permanent" in the image you do need a
class to hang it on, and a package to hold that.  Doing this only in-Image
is quite light and quick to do, and makes it easy to find later.  In a
System Browser create package "GHBibDeskStuff", class
GBibDeskKeywordFixer.  Create your method so you can use it from playground
like this...

 GBibDeskKeywordFixer new fixFile.

Then to the class side of GBibDeskKeywordFixer also add a method #fixFile
like this...
GBibDeskKeywordFixer class >> fixFile
  self new fixFile.

so that from playground you can drop the "new" and use it like this...

GBibDeskKeywordFixer fixFile


Feels like you've added a new command to Pharo?

Note that "GBibDeskKeywordFixer class >>" is just a documentation
convention indicating you should click the  button to add a method
to the class-side.

cheers -ben

Re: [Pharo-users] Wiring objects, IoC and Service Locator

[aryehof]

Consider that in Java, one can /only /achieve polymorphic behavior across
objects by using /interfaces /or /inheritance/.  In Smalltalk one can
achieve polymorphic behavior across objects just by *having them understand
the same message*.

The need to have complex schemes for the wiring of objects in Java is a
consequence of this.



--
View this message in context: 
http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4951174.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.